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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Post Messages to: [email protected]
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/[email protected]
** 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.

Reply via email to