OK, first, I think the reason you're trying to do this with a view instead of using the table directly, is for cases where the back end is SQL Server. If you use an identity field for the PK in SQL Server, this technique won't work anyway. SQL Server assigns the value to that field when you create the record, so you need a different technique.

Given that, I think you're causing yourself more grief than necessary by trying to do this with a view. Still, it should work for VFP tables, if you're using the correct setup. You should never open the source table for the view in a case like this. You should let VFP do it. I have a feeling you're opening the source table yourself, and it's ending up buffered. You can check this by using ? CURSORGETPROP("Buffering","SYSINFO") somewhere after you know the SYSINFO table is open. If you get back a 3 or 5, that's a problem.

>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,