Gret,

Cursors v. tables v. arrays: For me, a lot depends on what I need. If I'm going to do an APPEND FROM then an array may not do the job if there are other fields that I haven't selected. I'm not sure how much time it takes to create an actual table (add the name to your directory) when it's on the local drive, but I know that creating a new table on our network is sloooowww.

You haven't really said what you are after. If you just want to know whether there is a particular record, INDEXSEEK without moving the record pointer is supposed to be the fastest. Or, if there is no appropriate index, you might try SELECTING COUNT(*) into an array. (Be sure to check the value, not the _TALLY!)

But neither of these puts you on the actual record! You would still have additional time to go to the actual record, but if chances are that there wasn't a record present then you would be time ahead with the INDEXSEEK().



>Rather than work out data type conversions and consistent expression lengths, I sometimes like to bypass a SEEK by using a combination of a SQL Select command that is followed immediately by a check of the _TALLY.
>
>I've selected into cursors, tables, and arrays and haven't necessarily figured out which one is best. Once it's written, the SEEK is certainly much faster to execute. The later approach helps me to deal with cases where _TALLY =0, _TALLY = 1, and _TALLY > 1 in a different manner.
>
>What ideas are out there on this issue including the fastest way to do the SELECT and _TALLY? I've faced this issue in the past and I'm facing it in work I'm doing right now.
>
>Thank you in advance.