VFP9SP2 (build 7423) on Win2K12 Terminal Server client user.
Screenshot: https://www.screencast.com/t/EYptATFR3ETW
Client said app that they have used since 2016 is now acting strange. In short, a record count being reported about a cursor was now erroneous. Underlying cause I found was that VFP was just filtering on the underlying table, returning the record count of the actual DBF instead of the record count returned in the query. Solution was to add the READWRITE clause.
*** mjb 06/24/2020 - dev note: select was settng _tally = 1 but yet RECCOUNT was using the Order.dbf instead! Solution was to add READWRITE clause. SELECT invoice ; FROM broker!order f1 ; WHERE vendor_id = liVendorID AND ven_inv = loRec.ven_inv ; INTO CURSOR cur2ndChance READWRITE
IF RECCOUNT('cur2ndChance') = 1 THEN && found it llFound = .T. liLoadNum = cur2ndChance.invoice ELSE this.AddToExceptionReport(loRec, RECCOUNT('cur2ndChance')) ENDIF USE IN SELECT('cur2ndChance') && done with it
Now again, keep in mind that this solution has been working for years...and when we did an update recently to the database (including the ORDER.dbf table), then this problem arose. We did NOT update this program!
I vaguely recall the Foxperts here saying how VFP, rather than create a new cursor, would filtering the underlying DBF instead, but what puzzles me is why this solution worked for 4 years and then suddenly didn't?!??!?
Appreciate your thoughts on this, --Mike
Correction...user is on a virtual machine with operating system being WINDOWS 10 PRO. (Server is Win 2K12R2)
On 6/24/2020 4:35 PM, MB Software Solutions, LLC wrote:
VFP9SP2 (build 7423) on Win2K12 Terminal Server client user.
Screenshot: https://www.screencast.com/t/EYptATFR3ETW
Client said app that they have used since 2016 is now acting strange. In short, a record count being reported about a cursor was now erroneous. Underlying cause I found was that VFP was just filtering on the underlying table, returning the record count of the actual DBF instead of the record count returned in the query. Solution was to add the READWRITE clause.
*** mjb 06/24/2020 - dev note: select was settng _tally = 1 but yet RECCOUNT was using the Order.dbf instead! Solution was to add READWRITE clause. SELECT invoice ; FROM broker!order f1 ; WHERE vendor_id = liVendorID AND ven_inv = loRec.ven_inv ; INTO CURSOR cur2ndChance READWRITE
IF RECCOUNT('cur2ndChance') = 1 THEN && found it llFound = .T. liLoadNum = cur2ndChance.invoice ELSE this.AddToExceptionReport(loRec, RECCOUNT('cur2ndChance')) ENDIF USE IN SELECT('cur2ndChance') && done with it
Now again, keep in mind that this solution has been working for years...and when we did an update recently to the database (including the ORDER.dbf table), then this problem arose. We did NOT update this program!
I vaguely recall the Foxperts here saying how VFP, rather than create a new cursor, would filtering the underlying DBF instead, but what puzzles me is why this solution worked for 4 years and then suddenly didn't?!??!?
Appreciate your thoughts on this, --Mike
If you don't need the overhead of a writable cursor you can also use NOFILTER to force the query engine to not just do a USE...AGAIN with a filter. As for why now, the simplest answer I can think of is there was something about the query and the source data where Rushmore decided the latter strategy was the best way to give the desired results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of MB Software Solutions, LLC Sent: Wednesday, June 24, 2020 5:24 PM To: profoxtech@leafe.com Subject: Re: Bizarre scenario solved by READWRITE clause on end of SELECT SQL
Correction...user is on a virtual machine with operating system being WINDOWS 10 PRO. (Server is Win 2K12R2)
On 6/24/2020 4:35 PM, MB Software Solutions, LLC wrote:
VFP9SP2 (build 7423) on Win2K12 Terminal Server client user.
Screenshot: https://www.screencast.com/t/EYptATFR3ETW
Client said app that they have used since 2016 is now acting strange. In short, a record count being reported about a cursor was now erroneous. Underlying cause I found was that VFP was just filtering on the underlying table, returning the record count of the actual DBF instead of the record count returned in the query. Solution was to add the READWRITE clause.
*** mjb 06/24/2020 - dev note: select was settng _tally = 1 but yet RECCOUNT was using the Order.dbf instead! Solution was to add READWRITE clause. SELECT invoice ; FROM broker!order f1 ; WHERE vendor_id = liVendorID AND ven_inv = loRec.ven_inv ; INTO CURSOR cur2ndChance READWRITE
IF RECCOUNT('cur2ndChance') = 1 THEN && found it llFound = .T. liLoadNum = cur2ndChance.invoice ELSE this.AddToExceptionReport(loRec, RECCOUNT('cur2ndChance')) ENDIF USE IN SELECT('cur2ndChance') && done with it
Now again, keep in mind that this solution has been working for years...and when we did an update recently to the database (including the ORDER.dbf table), then this problem arose. We did NOT update this program!
I vaguely recall the Foxperts here saying how VFP, rather than create a new cursor, would filtering the underlying DBF instead, but what puzzles me is why this solution worked for 4 years and then suddenly didn't?!??!?
Appreciate your thoughts on this, --Mike
The ONLY change I can see in the Order.dbf was that I added a INDEX ON DELETED() tag DelFlag. Must have been that!!!! I know that changed the optimization level slightly from partial to full.
On 6/24/2020 5:35 PM, Richard Kaye wrote:
If you don't need the overhead of a writable cursor you can also use NOFILTER to force the query engine to not just do a USE...AGAIN with a filter. As for why now, the simplest answer I can think of is there was something about the query and the source data where Rushmore decided the latter strategy was the best way to give the desired results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of MB Software Solutions, LLC Sent: Wednesday, June 24, 2020 5:24 PM To: profoxtech@leafe.com Subject: Re: Bizarre scenario solved by READWRITE clause on end of SELECT SQL
Correction...user is on a virtual machine with operating system being WINDOWS 10 PRO. (Server is Win 2K12R2)
On 6/24/2020 4:35 PM, MB Software Solutions, LLC wrote:
VFP9SP2 (build 7423) on Win2K12 Terminal Server client user.
Screenshot: https://www.screencast.com/t/EYptATFR3ETW
Client said app that they have used since 2016 is now acting strange. In short, a record count being reported about a cursor was now erroneous. Underlying cause I found was that VFP was just filtering on the underlying table, returning the record count of the actual DBF instead of the record count returned in the query. Solution was to add the READWRITE clause.
*** mjb 06/24/2020 - dev note: select was settng _tally = 1 but yet RECCOUNT was using the Order.dbf instead! Solution was to add READWRITE clause. SELECT invoice ; FROM broker!order f1 ; WHERE vendor_id = liVendorID AND ven_inv = loRec.ven_inv ; INTO CURSOR cur2ndChance READWRITE
IF RECCOUNT('cur2ndChance') = 1 THEN && found it llFound = .T. liLoadNum = cur2ndChance.invoice ELSE this.AddToExceptionReport(loRec, RECCOUNT('cur2ndChance')) ENDIF USE IN SELECT('cur2ndChance') && done with it
Now again, keep in mind that this solution has been working for years...and when we did an update recently to the database (including the ORDER.dbf table), then this problem arose. We did NOT update this program!
I vaguely recall the Foxperts here saying how VFP, rather than create a new cursor, would filtering the underlying DBF instead, but what puzzles me is why this solution worked for 4 years and then suddenly didn't?!??!?
Appreciate your thoughts on this, --Mike
[excessive quoting removed by server]
Mixing the DBF() model and the SQL model causes funny stuff like this. Why it ever worked... oh, wait, just saw your last post: adding DELETED() means that a Rushmore-izable filter could be defined on indexes, which it could not before. That's why.
if you did a SELECT COUNT(*) instead, you wouldn't have to check RECCOUNT(). Or _TALLY. Or avoid SQK altogether with LOCATE and FOUND(), SEEK, even.
On Wed, Jun 24, 2020 at 5:52 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
The ONLY change I can see in the Order.dbf was that I added a INDEX ON DELETED() tag DelFlag. Must have been that!!!! I know that changed the optimization level slightly from partial to full.
On 6/24/2020 5:35 PM, Richard Kaye wrote:
If you don't need the overhead of a writable cursor you can also use
NOFILTER to force the query engine to not just do a USE...AGAIN with a filter. As for why now, the simplest answer I can think of is there was something about the query and the source data where Rushmore decided the latter strategy was the best way to give the desired results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of MB
Software Solutions, LLC
Sent: Wednesday, June 24, 2020 5:24 PM To: profoxtech@leafe.com Subject: Re: Bizarre scenario solved by READWRITE clause on end of
SELECT SQL
Correction...user is on a virtual machine with operating system being
WINDOWS 10 PRO. (Server is Win 2K12R2)
On 6/24/2020 4:35 PM, MB Software Solutions, LLC wrote:
VFP9SP2 (build 7423) on Win2K12 Terminal Server client user.
Screenshot: https://www.screencast.com/t/EYptATFR3ETW
Client said app that they have used since 2016 is now acting strange. In short, a record count being reported about a cursor was now erroneous. Underlying cause I found was that VFP was just filtering on the underlying table, returning the record count of the actual DBF instead of the record count returned in the query. Solution was to add the READWRITE clause.
*** mjb 06/24/2020 - dev note: selectwas settng _tally = 1 but yet RECCOUNT was using the Order.dbf instead! Solution was to add READWRITE clause. SELECT invoice ; FROM broker!order f1 ; WHERE vendor_id = liVendorID AND ven_inv = loRec.ven_inv ; INTO CURSOR cur2ndChance READWRITE
IF RECCOUNT('cur2ndChance') = 1 THEN&& found it llFound = .T. liLoadNum = cur2ndChance.invoice ELSE this.AddToExceptionReport(loRec, RECCOUNT('cur2ndChance')) ENDIF USE IN SELECT('cur2ndChance') && done with it
Now again, keep in mind that this solution has been working for years...and when we did an update recently to the database (including the ORDER.dbf table), then this problem arose. We did NOT update this program!
I vaguely recall the Foxperts here saying how VFP, rather than create a new cursor, would filtering the underlying DBF instead, but what puzzles me is why this solution worked for 4 years and then suddenly didn't?!??!?
Appreciate your thoughts on this, --Mike
[excessive quoting removed by server]
When I looked at the code, I thought the same thing--why not use LOCATE or SEEK...but then I remembered I can't...because as you can see in that call to AddToExceptionReport, I need the count of how many MORE records matched the criteria.
Gotta say this kinda soured me on adding DELETED() index tags. I know...test and find out which is better....but if it improves some queries but causes freak side effects like this, then no, I'll take the subsecond hit.
On 6/24/2020 7:16 PM, Ted Roche wrote:
Mixing the DBF() model and the SQL model causes funny stuff like this. Why it ever worked... oh, wait, just saw your last post: adding DELETED() means that a Rushmore-izable filter could be defined on indexes, which it could not before. That's why.
if you did a SELECT COUNT(*) instead, you wouldn't have to check RECCOUNT(). Or _TALLY. Or avoid SQK altogether with LOCATE and FOUND(), SEEK, even.
On Wed, Jun 24, 2020 at 5:52 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
The ONLY change I can see in the Order.dbf was that I added a INDEX ON DELETED() tag DelFlag. Must have been that!!!! I know that changed the optimization level slightly from partial to full.
On 6/24/2020 5:35 PM, Richard Kaye wrote:
If you don't need the overhead of a writable cursor you can also use
NOFILTER to force the query engine to not just do a USE...AGAIN with a filter. As for why now, the simplest answer I can think of is there was something about the query and the source data where Rushmore decided the latter strategy was the best way to give the desired results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of MB
Software Solutions, LLC
Sent: Wednesday, June 24, 2020 5:24 PM To: profoxtech@leafe.com Subject: Re: Bizarre scenario solved by READWRITE clause on end of
SELECT SQL
Correction...user is on a virtual machine with operating system being
WINDOWS 10 PRO. (Server is Win 2K12R2)
On 6/24/2020 4:35 PM, MB Software Solutions, LLC wrote:
VFP9SP2 (build 7423) on Win2K12 Terminal Server client user.
Screenshot: https://www.screencast.com/t/EYptATFR3ETW
Client said app that they have used since 2016 is now acting strange. In short, a record count being reported about a cursor was now erroneous. Underlying cause I found was that VFP was just filtering on the underlying table, returning the record count of the actual DBF instead of the record count returned in the query. Solution was to add the READWRITE clause.
*** mjb 06/24/2020 - dev note: selectwas settng _tally = 1 but yet RECCOUNT was using the Order.dbf instead! Solution was to add READWRITE clause. SELECT invoice ; FROM broker!order f1 ; WHERE vendor_id = liVendorID AND ven_inv = loRec.ven_inv ; INTO CURSOR cur2ndChance READWRITE
IF RECCOUNT('cur2ndChance') = 1 THEN&& found it llFound = .T. liLoadNum = cur2ndChance.invoice ELSE this.AddToExceptionReport(loRec, RECCOUNT('cur2ndChance')) ENDIF USE IN SELECT('cur2ndChance') && done with it
Now again, keep in mind that this solution has been working for years...and when we did an update recently to the database (including the ORDER.dbf table), then this problem arose. We did NOT update this program!
I vaguely recall the Foxperts here saying how VFP, rather than create a new cursor, would filtering the underlying DBF instead, but what puzzles me is why this solution worked for 4 years and then suddenly didn't?!??!?
Appreciate your thoughts on this, --Mike
[excessive quoting removed by server]
MYSTERY SOLVED! IT *WAS* THE DELETED INDEX THAT CAUSED THE CHANGE IN BEHAVIOR! I dropped the index, re-ran with the code as it's been the past 4 years, and it worked completely fine.
So much for my seeing if the DELETED() index helped. As I said...I don't think any very small performance gain would be worth the aggravation this caused. (Made me doubt other areas working for years too....you know, the things nobody yet noticed or told you about?!?!?)
Thanks all for your thoughts, --Mike
On 6/24/2020 5:51 PM, MB Software Solutions, LLC wrote:
The ONLY change I can see in the Order.dbf was that I added a INDEX ON DELETED() tag DelFlag. Must have been that!!!! I know that changed the optimization level slightly from partial to full.
On 6/24/2020 5:35 PM, Richard Kaye wrote:
If you don't need the overhead of a writable cursor you can also use NOFILTER to force the query engine to not just do a USE...AGAIN with a filter. As for why now, the simplest answer I can think of is there was something about the query and the source data where Rushmore decided the latter strategy was the best way to give the desired results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of MB Software Solutions, LLC Sent: Wednesday, June 24, 2020 5:24 PM To: profoxtech@leafe.com Subject: Re: Bizarre scenario solved by READWRITE clause on end of SELECT SQL
Correction...user is on a virtual machine with operating system being WINDOWS 10 PRO. (Server is Win 2K12R2)
On 6/24/2020 4:35 PM, MB Software Solutions, LLC wrote:
VFP9SP2 (build 7423) on Win2K12 Terminal Server client user.
Screenshot: https://www.screencast.com/t/EYptATFR3ETW
Client said app that they have used since 2016 is now acting strange. In short, a record count being reported about a cursor was now erroneous. Underlying cause I found was that VFP was just filtering on the underlying table, returning the record count of the actual DBF instead of the record count returned in the query. Solution was to add the READWRITE clause.
*** mjb 06/24/2020 - dev note: select was settng _tally = 1 but yet RECCOUNT was using the Order.dbf instead! Solution was to add READWRITE clause. SELECT invoice ; FROM broker!order f1 ; WHERE vendor_id = liVendorID AND ven_inv = loRec.ven_inv ; INTO CURSOR cur2ndChance READWRITE
IF RECCOUNT('cur2ndChance') = 1 THEN && found it llFound = .T. liLoadNum = cur2ndChance.invoice ELSE this.AddToExceptionReport(loRec, RECCOUNT('cur2ndChance')) ENDIF USE IN SELECT('cur2ndChance') && done with it
Now again, keep in mind that this solution has been working for years...and when we did an update recently to the database (including the ORDER.dbf table), then this problem arose. We did NOT update this program!
I vaguely recall the Foxperts here saying how VFP, rather than create a new cursor, would filtering the underlying DBF instead, but what puzzles me is why this solution worked for 4 years and then suddenly didn't?!??!?
Appreciate your thoughts on this, --Mike
[excessive quoting removed by server]
On Jun 24, 2020, at 21:32, MB Software Solutions, LLC mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
So much for my seeing if the DELETED() index helped. As I said...I don't think any very small performance gain would be worth the aggravation this caused. (Made me doubt other areas working for years too....you know, the things nobody yet noticed or told you about?!?!?)
https://fox.wikis.com/wc.dll?Wiki~NonDiscriminatingIndex
-- Ed Leafe
' Another classic case is Gender: you always get half the population as hits.' Not really true anymore...LOL
On Thu, Jun 25, 2020 at 2:45 PM Ed Leafe ed@leafe.com wrote:
On Jun 24, 2020, at 21:32, MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
So much for my seeing if the DELETED() index helped. As I said...I
don't think any very small performance gain would be worth the aggravation this caused. (Made me doubt other areas working for years too....you know, the things nobody yet noticed or told you about?!?!?)
https://fox.wikis.com/wc.dll?Wiki~NonDiscriminatingIndex
-- Ed Leafe
[excessive quoting removed by server]
Maybe your server should reindex all DBFs every night after office hours! That's what an 10-year-old FoxPro/DOS MIS system I used to maintain was doing.... :)
On Thu, Jun 25, 2020 at 10:33 AM MB Software Solutions, LLC mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
MYSTERY SOLVED! IT *WAS* THE DELETED INDEX THAT CAUSED THE CHANGE IN BEHAVIOR! I dropped the index, re-ran with the code as it's been the past 4 years, and it worked completely fine.
So much for my seeing if the DELETED() index helped. As I said...I don't think any very small performance gain would be worth the aggravation this caused. (Made me doubt other areas working for years too....you know, the things nobody yet noticed or told you about?!?!?)
How does that have anything to do with the price of tea in China? lol
It wasn't that an index was out of whack; it's that the attempt to fully optimize caused VFP to unfortunately filter the table instead of give me an inaccurate count of the cursor.
On 6/26/2020 11:06 AM, Man-wai Chang wrote:
Maybe your server should reindex all DBFs every night after office hours! That's what an 10-year-old FoxPro/DOS MIS system I used to maintain was doing.... :)
On Thu, Jun 25, 2020 at 10:33 AM MB Software Solutions, LLC mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
MYSTERY SOLVED! IT *WAS* THE DELETED INDEX THAT CAUSED THE CHANGE IN BEHAVIOR! I dropped the index, re-ran with the code as it's been the past 4 years, and it worked completely fine.
So much for my seeing if the DELETED() index helped. As I said...I don't think any very small performance gain would be worth the aggravation this caused. (Made me doubt other areas working for years too....you know, the things nobody yet noticed or told you about?!?!?)
That sounds more like a program bug then... :)
That app I was talking about didn't use database container, all DBFs. And no triggers.
On Sat, Jun 27, 2020 at 2:11 AM MB Software Solutions, LLC mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
How does that have anything to do with the price of tea in China? lol
It wasn't that an index was out of whack; it's that the attempt to fully optimize caused VFP to unfortunately filter the table instead of give me an inaccurate count of the cursor.
Hi all,
I may have an opportunity to move our MSSQL backends to MariaDB.
One thing I really love about MSSQL is the Server Manager. It makes maintenance, modifications, server rights, etc, etc, etc easy.
I'm wondering what you're using for MariaDB? So far I've found and looked at Heidi, and while it' a lot better than just command line, I'm not terribly impressed.
What tools would you recommend? Thanks!
SQLYog is my go-to beyond HeidiSQL. Admittedly, I just use SQLYog for schema comparison and automatic update SQL generation to get things in sync.
Curious -- why dump SQL Server? Costs???
On 7/10/2020 11:06 AM, Vince Teachout wrote:
Hi all,
I may have an opportunity to move our MSSQL backends to MariaDB.
One thing I really love about MSSQL is the Server Manager. It makes maintenance, modifications, server rights, etc, etc, etc easy.
I'm wondering what you're using for MariaDB? So far I've found and looked at Heidi, and while it' a lot better than just command line, I'm not terribly impressed.
What tools would you recommend? Thanks!
On 07/10/20 11:12 AM, MB Software Solutions, LLC wrote:
SQLYog is my go-to beyond HeidiSQL. Admittedly, I just use SQLYog for schema comparison and automatic update SQL generation to get things in sync.
Curious -- why dump SQL Server? Costs???
Yes, costs. We'll be required to use Enterprise edition when we migrate. $$$$
Why will you have to go to Enterprise? We are dumping enterprise on 3 servers with 13 instances and hundreds of dbs. Only keeping one server for BI capabilities. Saving us around 650K in licensing.
Why do you need to push to Ent?
On Fri, Jul 10, 2020 at 12:06 PM Vince Teachout vinny@caracal.net wrote:
On 07/10/20 11:12 AM, MB Software Solutions, LLC wrote:
SQLYog is my go-to beyond HeidiSQL. Admittedly, I just use SQLYog for schema comparison and automatic update SQL generation to get things in sync.
Curious -- why dump SQL Server? Costs???
Yes, costs. We'll be required to use Enterprise edition when we migrate. $$$$
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
On Jul 10, 2020, at 10:06, Vince Teachout vinny@caracal.net wrote:
I'm wondering what you're using for MariaDB? So far I've found and looked at Heidi, and while it' a lot better than just command line, I'm not terribly impressed.
https://codingsight.com/10-best-mysql-gui-tools/
I use phpMyAdmin occasionally, but mostly just work from the command line.
-- Ed Leafe
On 6/24/2020 5:35 PM, Richard Kaye wrote:
If you don't need the overhead of a writable cursor you can also use NOFILTER to force the query engine to not just do a USE...AGAIN with a filter. As for why now, the simplest answer I can think of is there was something about the query and the source data where Rushmore decided the latter strategy was the best way to give the desired results.
I've honestly never used the NOFILTER clause. How much overhead does READWRITE cause vs. the NOFILTER I wonder? Are we again talking about something negligible?
In the real world it's probably negligible. I almost always use READWRITE.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of MB Software Solutions, LLC Sent: Wednesday, June 24, 2020 10:25 PM To: profoxtech@leafe.com Subject: Re: Bizarre scenario solved by READWRITE clause on end of SELECT SQL
On 6/24/2020 5:35 PM, Richard Kaye wrote:
If you don't need the overhead of a writable cursor you can also use NOFILTER to force the query engine to not just do a USE...AGAIN with a filter. As for why now, the simplest answer I can think of is there was something about the query and the source data where Rushmore decided the latter strategy was the best way to give the desired results.
I've honestly never used the NOFILTER clause. How much overhead does READWRITE cause vs. the NOFILTER I wonder? Are we again talking about something negligible?
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/a0003bb4-5356-d95d-7e7a-121d122e965d@mbsoft... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious. Report [OT] Abuse: http://leafe.com/reportAbuse/a0003bb4-5356-d95d-7e7a-121d122e965d@mbsoftware...
On 6/24/2020 10:53 PM, Richard Kaye wrote:
In the real world it's probably negligible. I almost always use READWRITE.
Ditto. Successful for 20 +/- years with it. :-)
I always just use READWRITE. Any potential few KB or microseconds saving from not using READWRITE became meaningless many years ago.
On 6/26/2020 10:15 AM, Alan Bourke wrote:
I always just use READWRITE. Any potential few KB or microseconds saving from not using READWRITE became meaningless many years ago.
Exactly...that's what I meant about "I'll take the sub-second performance hit."
The INDEX on DELETED is absolutely ok, if you do it as a BINARY index. The BINARY index is basically the rushmore map. Each record is represented as one bit, thus the resulting indexmap is way smaller and faster than the traditional indexing map.
[excessive quoting removed by server]
I did set it as BINARY index. I changed all my logical field indexes to binary a long time ago. My reasoning for what I said is that I would have to go back to anywhere where I didn't have the READWRITE or NOFILTER clause and expected to show the RECCOUNT() like the example I posted, then it would be wrong. Recall my example wasn't about locating a particular record but knowing how many it was if not a single match.
On 6/25/2020 5:07 AM, Jürgen Wondzinski wrote:
The INDEX on DELETED is absolutely ok, if you do it as a BINARY index. The BINARY index is basically the rushmore map. Each record is represented as one bit, thus the resulting indexmap is way smaller and faster than the traditional indexing map.
[excessive quoting removed by server]
-
Alan Bourke -
Ed Leafe -
Jean Laeremans -
Jürgen Wondzinski -
Man-wai Chang -
MB Software Solutions, LLC -
Richard Kaye -
Stephen Russell -
Ted Roche -
Vince Teachout