Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Problem with RecNo() in SQL query
Message
From
11/03/2002 04:00:17
 
 
To
11/03/2002 03:21:30
Eugene Kolmakov
Millennium Technologies
Vladivostok, Russia
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00630834
Message ID:
00630839
Views:
17
>I need to combine some tables in SQL query and I also need to get the first table's records numbers.
>
>I try to build SQL query like this:
>
>Select RecNo() as RecNo_, tbl1.fld1, tbl2.fld1 from tbl1, tbl2 where tbl1.keyfield1 = tbl2.keyfield1
>
>and it works fine, but when I try to run query on three tables like this:
>
>Select RecNo() as RecNo_, tbl1., tbl2., tbl3. from tbl1, tbl2, tbl3 where tbl1.keyfield1 = tbl2.keyfield1 and tbl2.keyfield2 = tbl3.keyfield1
>
>then RecNo() returns the wrong values for the first table record numbers.

The obvious question is which RECNO() is involved, and is it taken from the source record or an intermediary. RECNO() is not a field, or a fixed attribute, of a record. In order to make it such, you need to store the RECNO() value to a field of the table before issuing the SQL SELECT statement. A better idea would be to use some sort of synthetic surrogate key - an arbitrary unique value associated with the record that remains static for the life of the record. RECNO() doesn't fit the bill, because the RECNO() of a given record may change over the life of the table as a result of deletions, packing and reordering of the file, and a given RECNO() may be assigned to several distinct records over the life of the table.

You would be better off simply assigning a sequentially allocated value to an integer field of the record and using it to uniquely locate the record.
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
Reply
Map
View

Click here to load this message in the networking platform