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 <
[email protected]> 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 <[email protected]> On Behalf Of MB
Software Solutions, LLC
Sent: Wednesday, June 24, 2020 5:24 PM
To: [email protected]
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: [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.
