One more idea. Quit using autoincrements and pool PKs.

>Hi Michael
>
>Two ways that I know of, both would probably take some work.
>1. Use composite keys. Have a siteno as well as a autoincrement key. This way there would never be a key violation but would take changing all the FKs as well.
>2. Add each new row one at a time and get the @@identity for the row changed and change all the FKs accordingly. Something like:
>

SQLEXEC(lnHndl,”insert into …..;select @@identity”,”mycursor”)

>
>>I'm accessing a SQL back end from ASP on the web side and Offline Views on the client side. Things are pretty straightforward for me because most tables will be updated from VFP only - Except for my 'registrants' table, where people register on-line.
>>
>>For this table, we'll be adding registrants in off-line mode at the same time that others are registering themselves on the web - so records will be added in both places.
>>
>>The previous web developer used a SQL Identity field as a PK in this table.
>>
>>I thought I'd be able to query the table each time we connect to figure out the next PK, then incriment my new local PK's to match (using a local PK table to figure out where the new ones start), then synchronize - but it seems like the @@IDENTITY function doesn't return anything until you attempt to save a record.
>>
>>How do others deal with PK generation when records are added from both sides?
>>
>>TIA