On 7/13/06, Michael Hawksworth <[EMAIL PROTECTED]> wrote:
I'm stumped.
I have a cursor curApprovedIDs3 that I can select and browse but can't
use in a sql select statement, it doesn't return any info.
When you execute a SQL statement to create a cursor, FoxPro creates a
file on disk, but may not populate it with any rows if it doesn't need
to. It does this to speed the operation. If the cursor can be
represented by a filtered view of an existing table (ex., "Select
lName, fName from Customer") then the filter is applied and no records
actually "exist" in the cursor.
When you try to run another SQL operation on the cursor, it can't find
any records. SQL operates independently of what you have in your work
areas and works directly with what's on disk.
Most of the time, this is a feature. Once in a while, it's a pain in the butt.
There are a couple of ways around this: if the original cursor is
directly off a table, you can usually get better performance by using
the same code you used to select the original cursor in the second
query. There are other alternatives: READWRITE forces a disk presence,
as does NOFILTER. INTO TABLE is another good alternative. Bear in mind
that the extracted result won't have indexes and will be slower in
join and filter operations than the original table. For fast hardware
and small data sets this can be insignificant.
--
Ted Roche
Ted Roche & Associates, LLC
http://www.tedroche.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** 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.
