Pardon me for jumping in.
Why not to generate the PK at client side? I've ended up using a locally generated PK using something like WorkstationID+sys(2015). I don't care anymore if the backend is Visual Foxpro or another server and I don't need a separate table to track next id(s) for tables.


>Hi again;
>
>I understand your point about getting a PK in VFP - I'm not using the view to set the primary key for the table the view is based on - that would mess up for sure.
>
>I use a single record table called SYSINFO in my systems that holds the next available primary keys for all of the PK's throughout the other system tables. When I need a new PK (for a different table), I go to my SYSINFO.DBF file and grab the next available one. Back in the DOS days, I would use the RLOCK() technique. Nowadays, I use an updatable view called VSYS instead. Suppose I need a new employee number for my employee table:
>
>I REQUERY(Vsys), pull out the next employee number, increment it and TableUpdate(). If it fails, I TableRevert() and start the process again, requery...etc. Once it has successfully updated the underlying SYSINFO.dbf I return the next employee number and update the primary key in my Employee file.
>
>Using this technique, the system doesn't care whether it's a local or remote view - it just runs the same code until it gets what it's after. If it fails, after the TableRevert and Requery the view looks clean and pristine - if I then increment the field and TableUpdate() again, it will fail every time with an update conflict.
>
>I never actually open the free table, the view does that all by itself. If I manually close the table the view is based on after the update conflict, it works perfectly. It boils down to this - when you Revert and Requery, it pulls from the modified base table properly to reset it's values - but when doing the TableUpdate, it appears to compare against the original base table values that were present when it originally opened the view.
>
>I've gotten around the issue by closing the underlying tables before saving a view, but that feels Kludgy. Everything works perfectly using FOX2X tables - I don't get it...
>
>Thanks for hanging in there with me. I sincerely appreciate your efforts.
>
>Best Regards,