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,