Re: Bizarre scenario solved by READWRITE clause on end of SELECT SQL (SOLVED)
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 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. -- .~. Might, Courage, Vision. SINCERITY! / v \ 64-bit Fedora 25 Server Spin /( _ )\ http://sites.google.com/site/changmw ^ ^ May the Force and farces be with you! ___ 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/CAGv=mjcp4t5fzaavpdt70mhk2ilfz-7t3f9rvk4si0pkuxw...@mail.gmail.com ** 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.
Re: Bizarre scenario solved by READWRITE clause on end of SELECT SQL (SOLVED)
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 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 tooyou know, the things nobody yet noticed or told you about?!?!?) -- 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/612afc92-73aa-13a6-ea50-a6b7fa05d...@mbsoftwaresolutions.com ** 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.
Re: Bizarre scenario solved by READWRITE clause on end of SELECT SQL (SOLVED)
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 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 > tooyou know, the things nobody yet noticed or told you about?!?!?) -- .~. Might, Courage, Vision. SINCERITY! / v \ 64-bit Fedora 25 Server Spin /( _ )\ http://sites.google.com/site/changmw ^ ^ May the Force and farces be with you! ___ 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/CAGv=MJDy3HtqQK=ooymiypx98y_2vxttmhdeubehvme2ayk...@mail.gmail.com ** 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.
Re: Bizarre scenario solved by READWRITE clause on end of SELECT SQL (SOLVED)
' 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 wrote: > On Jun 24, 2020, at 21:32, MB Software Solutions, LLC < > mbsoftwaresoluti...@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 tooyou 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] ___ 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/capqlobwejfhzyyvpbffz1fxazsq+ng2mkk-9hwag1mt6cdt...@mail.gmail.com ** 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.
Re: Bizarre scenario solved by READWRITE clause on end of SELECT SQL (SOLVED)
On Jun 24, 2020, at 21:32, MB Software Solutions, LLC 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 tooyou know, the > things nobody yet noticed or told you about?!?!?) https://fox.wikis.com/wc.dll?Wiki~NonDiscriminatingIndex -- Ed Leafe ___ 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/9aea3265-c9ef-4a82-878b-577a706ae...@leafe.com ** 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.
Re: Bizarre scenario solved by READWRITE clause on end of SELECT SQL (SOLVED)
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
tooyou 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 On Behalf Of MB
Software Solutions, LLC
Sent: Wednesday, June 24, 2020 5:24 PM
To: profoxt...@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]
___
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/933bdd57-ca55-582c-16ba-aefd4f66b...@mbsoftwaresolutions.com
** 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.
