Snip...
>>Instead of inserting values by hand to a PK field create a PKgenerator routine and set the default value of field to that value (ie:PKfielddefval=myPKgenerate(cTable,cType)). For an easier way you could try using sys(2015) as a default value for a PK field char(10).
>>Cetin
>
>I don't think that using a generator would change anything. You can't be 100% sure that a generated key is a unique one. So in effect you have to check uniqueness:
>
>DO WHILE .T.
> lcKey = generate(...)
> IF !SEEK(lcKey)
> EXIT
> ENDIF
>ENDDO
>
>As I know filtered keys have no meaning for rushmore - VFP doesn't use it.
>'Tab_del' and 'Field' indexes have to be regular and you must keep them for rushmore. 'Tab_pk' is the only primary/candidate key.

First, a deleted record doesn't mean you could use its PK value, unless packed. So it would be meaningless to use a filtered key or a tag on deleted() just for PK check (a dummy tag on deleted() have always purpose, but not this one).
With a generator routine you could be 100% sure that a key is unique w/o checking it. Of course you would need some checking on startup. Below there are two routines generating unique PK's for a given station :

function GenerateDoublePK
* Accuracy for seconds() is 1 millisec on Win95
* 10 millisecs in NT
start=seconds()
do while seconds()-start < 0.1   && Delay to be sure of in accuarcy limits
enddo
return val(dtos(date()))*10^8+seconds()*1000

function GenerateCharPK
* sys(2015) return different value even called in same millisecond interval
return sys(2015)

In the range VFP can process date type (1/1/100-12/31/9999), max DoublePK value would be 7 bytes (and in fact some bits in 7th byte) thus leaving you one byte for multiuser purposes. So with generating Double type PK you could support at least 255 workstations in this sense.
With second char PK approach it's easier to manage. For a single user app you would just use sys(2015) as a default value. For multiuser you could add some chars to keep the stationID.
For both routines, since they're based on datetime, you should check the system clock is not smaller than last update (beware lupdate() fail in Y2000) on startup.
Creating an ID holder table is another solution (as in solutions.app).
With below routine, whether key is app generated or not, you would have the potential of having a NONUNIQUE key (provided generator needs check also). Because in a multiuser environment you won't have the ability to SEEK other users buffered PK. This would mean you should postpone the PK till tableupdate (maybe use a dummy value and change afterwards).

DO WHILE .T.
   lcKey = generate(...)
   IF !SEEK(lcKey)      && You only seek your buffer+physically written !
      EXIT
   ENDIF
ENDDO

And finally below routine shows how sys(2015) is UNIQUE on a given station.

dimension myArray[10]
for ix = 1 to 10
   mYArray[ix]=sys(2015)
endfor
for ix = 1 to 10
   ? mYArray[ix]
endfor

Cetin