>>All my tests show SYS(2015) is unique in a given VFP session, but I don't believe it's unique across machines,
>
>Hi Tamar, I agree with you with this.
>
>> and probably not across separate sessions on a single machine (though I've never tested that).
>
>About that, I ran a probably flawed test, in it I wait for the next minute to start to populate a cursor, then I add the cursor's data to a table, I ran the same code for 3 different fox pro sessions ending up with a table with 3 million records with zero collision, all values unique, the program was:
>
>

>CREATE CURSOR c_test (PK I AUTOINC, VALUE C(10))
>
>IF FILE('c:\temp\test_unique.dbf')
>ELSE
>	create table c:\temp\test_unique (PK I, VALUE C(10))
>endif
>
>USE c:\temp\test_unique IN SELECT('test_unique') AGAIN shared
>
>* start at an specific time
>clear
>ldScheduled			= DATETIME(null, null, null, HOUR(DATETIME()), (MINUTE(DATETIME()) + 1) % 60, 0)
>DO WHILE DATETIME() < ldScheduled
>ENDDO
>
>? 'Started at: ', SECONDS(), 'Time: ', DATETIME(), 'Scheduled: ', ldScheduled font "Courier New", 10
>
>lnStart			= SECONDS()
>
>FOR i = 1 TO 1000000
>	INSERT INTO c_test (value) VALUES (SYS(2015))
>NEXT i
>
>? SECONDS() - lnStart
>
>SELECT test_unique
>APPEND FROM DBF('c_test')
>
>

>
>The programs started all withing a hundredth? of a second at 47580.012, 47580.007 and 47580.004 and they ran for .754, .809 and .931. Considering that they are creating 1000+ records per millisecond, it means that it is quite likely that they were creating records at the exact same time, (I know I am exaggerating) but getting a different SYS(2015) value nonetheless, so, in short it seems that it generates different values across sessions.
>
>This does not mean that I am disregarding other's experience, and I am even posting my code to 1) validate it and 2) maybe someone else running it gets duplicate values, after all more than one poster is telling me that they've got the same value, but that has never been my experience


Try with RDP - 50 users. There will be duplicate records at last, be sure...