Now that I think about it a little more, I cannot do what you are saying. I have used the "table of next keys" approach before, but in this application I need guaranteed unique numbers for .exe's that talk to each other, so there is a chance that numbers will end up being the same if the "table of next keys" gets out of sync.

However, if I generate 2 million unique numbers, then give each of my 4 .exe's their own 500,000 to use, I know there is no way that they will ever step on each other.

I just wish the SQL-Select was optimized better for this. This is supposed to be one of VFP's strongest points and this simple query is not working.

I am going to beat this horse some more. Two integer columns. 500,000 rows.
The test code:

Clear
Public cLvl
Sys (3054,1,"cLvl")
iThen = Seconds()
Select min(iValue) from UniqInt02 Where iDel=0 Into Cursor Nono NoWait
? Seconds() - iThen
? cLvl

1. With no index on iValue and iDel
.0969
Rushmore optimization level for table uniqint02: none

2. With an index on iDel
1.015
Rushmore optimization level for table uniqint02: partial

3. With an index on iValue and iDel
1.015
Rushmore optimization level for table uniqint02: partial


So it seems like no optimization is better than partial. However, I would like full. Should I go to another data type or something?


>Because despite the "TOP 1" ODER BY in the query cause getting the entire table for sorting. THis is slow approach, indeed. There are other approaches. One of them is to use the table that store last ID for each table (described in many places, you can read about it in the FAQ article at the www.tek-tips.com site, VFP forum).