Thank you! You've been very helpful!

<snip>
>Joe,
>It was why I said dangerous. In a multiuser app more than one user has a high chance to get the same id. Or even a single computer might get the same id (user deletes some from bottom and thus gets previously used id - it would be a real problem if children also not deleted and packed).
>Yes it was NewId what I was referring. It's not bad since an integer is large enough to accomodate a table limit even with multipl unused PKs (in theory you could hit the limit of an integer before table limit but in practice? - further you could do a maintanence to recover unused PKs). And PKs are relation insurances not things that users should or would see.
>My NewId is sligthly modified version :
>Ids: Table c(15), NextId i && Warning if you have a chance to give a tablename more than 15 chars either take that into account in ids structure or do something like windows shortnaming convention. Otherwise you could take always 1 as a PK for a particular table.
>
>FUNCTION NewID
> LPARAMETERS tcAlias
> LOCAL lcAlias
> * Uppercase Alias name
> lcAlias = upper(iif(parameters() = 0, alias(), tcAlias))
> lcOldExact = set('exact')
> set exact on
> * Lock reprocess - try once
> SET REPROCESS TO 1
> IF !USED("IDS")
> USE ids IN 0
> ENDIF
> * If no entry yet create and return 1
> IF !SEEK(lcAlias, "Ids", "table")
> INSERT into ids (Table, NextId) values (lcAlias,1)
> set exact &lcOldExact
> RETURN ids.NextId
> ENDIF
> set exact &lcOldExact
> * Lock, increment id, unlock, return nextid value
> DO while !RLOCK('ids')
> * Delay before next lock trial
> lnStart = seconds()
> DO while seconds()-lnStart < 0.01
> ENDDO
> ENDDO
> * Increment
> REPLACE ids.NextId WITH ids.NextId + 1 in 'ids'
> UNLOCK in 'ids'
> RETURN ids.NextId
>ENDFUNCIntentionally automatic reprocess is not used and a short delay is given between trials to prevent deadlock.
>Cetin