>>>>>>>>>>>>>>>>>>>>>>>>>>>
The updateable recordset seemed to be the clue. But now the stored procs in the dbc are not calculating the primary key value.
>>>>>>>>>>>>>>>>>>>>>>>>>>>

The ado recordset does not set the newid value until you write back to the database. In other words, AddNew() doesn't trigger any default value code.

I assume that you are using the ADO/OLEDB ODBC driver. If that's the case, just don't bring your ID field over with the rest of the table. This way, when you write the record back, there's no ID value already set, and the database should write the value for you. If that's not an option, I have one other idea -- I haven't tried this before posting, so tread carefully -- but wheat if you remove the ID field from the fields collection prior to AddNew() and update? Again, since the database isn't receiving back any ID field data (not even blank strings) it may write the value back on the engine-end. Just a thought.

Once we get an OLEDB VFP driver, you should (?) be able to call the stored procedures in a database directly (as you can now do with SQL Server), so you could actually .AddNew(), call NewIDProc(), get the value, and stuff it in. The problem is, this requires two trips to the back end -- on the other hand, if you really need to know what the next autoincrementing id will be, for some other action you plan on taking (adding child tables to a whole other recordset, for instance) this works (albeit not as quickly).

Hope this helps some.