Phil,

I would look for code that accesses the NextRef table directly rather than using the common function provided. It may be something used infrequently (or more < s >) but in any case it may be mucking up the 'next' value afer it uses the current one. For instance, assuming that it tries to lock the table or record, it may be assuming success of the locking operation rather than handling a failure (to lock) condition.

Frankly, the network would be near the bottom of my list because i would expect other difficulties as well in such a situation.

good luck

>Hi.
>We have a number of legacy aplications here which are written in fox for dos. Many of the tables used in the applications contain unique keys. We often get problems caused by duplication of unique keys and I can't work out why or how to stop it happening.
>For each table in the system the value for the last unique key generated is stored in a table called nextref.
>When a new record is added to a table the nextref table is locked. The appropriate value is read from nextref and stored in the table being appended as the unique identifier for the new record. The value for that identifier is incremented in the nextref table before the lock is released.
>We have also inserted a function which checks that the identifier does not already exist in the table before storing it to the new record.
>Reprocess is set to automatic.
>
>I think that the duplications are probably caused by network errors but I don't know how that would happen exactly.
>
>
>Phil.