Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Really Wierd Record Locking Problem
Message
From
28/10/1999 04:24:11
 
 
To
27/10/1999 23:30:58
General information
Forum:
Visual FoxPro
Category:
FoxPro 2.x
Miscellaneous
Thread ID:
00282185
Message ID:
00282852
Views:
29
>Hi Missy
>
>Thanks, for the reply. The reason I changed to a copy to command is that it is my understanding that sometimes in FPW26 if you do an SQL Select statement and direct it to a table, FPW may have a mind of its own and still make it a cursor instead of a table. This is particularly likely if the SELECT statement has no derived fields.
>

Not really. The real facts:

When SELECTing to a CURSOR, where the data comes as a result of a fully Rushmore-optimzable query, you may end up with a filtered view of the table rather than a 'real' cursor - while examining the data in the "cursor" created this way, the RECCOUNT() is acyally the number of records in the table, and all sorts of strange things may happen once the query completes if you then try to index or do a SET FILTER to the "cursor: formed in this fashion.

This behavior persists in VFP; VFP6 introduced the introduced the NOFILTER clause, which forces the cursor to be formed rather than simply providing a filtered view of the data.

There are simple workarounds:

(1) Add a non-optimzable expression to the WHERE clause (SHUDDER). It's not as bad as it sounds - adding a logical expression that can't be resolved by Rushmore's use of indexes to pick values does this, and it doesn't have to actually do any data manipulation. If we have a CUSTOMER table with an index on the field cState, the following might result in a filtered view rather than a cursor:

SELECT * FROM Customer ;
INTO CURSOR Temp ;
WHERE cState = 'CT'

This simple change forces a 'real' cursor to be created, at low processing cost:

SELECT * FROM Customer ;
INTO CURSOR Temp ;
WHERE cState = 'CT' AND .T.

(2) If data comes from >1 table, a real cursor is always formed:

SELECT Cust.Name, Inv.InvDate, Inv.Amt ;
FROM Cust, Inv ;
WHERE Inv.CustNo = Cust.CustNo

(3) If a computed value is referenced in the output, a real cursor is formed:

SELECT CustNo, Amt, DATE() - InvDate AS InvAge ;
FROM Inv ;
INTO CURSOR Temp

(4) If a GROUP BY or HAVING clause is used, a real cursor is formed.

In general, adding AND .T. to the WHERE clause is the least expensive way to ensure that a cursor will be formed priot to VFP6, and the difference in performance between it and NOFILTER in VFP6 is VERY small...
>Even though the query I wrote does have derived field in it I didn't want to take any chance so I did a query and copy.
>
>It sounds like I have a couple of real good other replys although I didn't have a chance to try any out as I just got back from New Orleans
>
>Thanks
>Pete Berlowitz
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform