Sorry I am unable to help, as I noted similar code works for me. I did run into one problem with your code where the update was failing, I believe the update failed because the recordset contained a general field (but I didn't pursue it). And I never did replicate only updating one record you originally noted.

The reason this thread interested me was because I have written similar functionality, but instead of calling the tableupdate() function, I use my own update() method. I tested my code against yours and also against remote views and mine was faster so I am going to stick with what I have (in my tests, my code was about 40% faster than remote views). My code basically relies on the recordset being buffered and then uses getnextmodified() to cycle through the records that have been updated and uses getfldstate() to build the update, delete or insert string.

One main issue I had with remote views and code similar to yours (other than being hard to debug) is how it handles empty dates (it defaults them to 1900-01-01 00:00:00.000 when writing to SQL Server). I guess you could write a trigger to set that value to NULL, but I don't really know another workaround. To me, 1900-01-01 is not acceptable so I wrote my own.

Just to test, you might try a remote view. If you are interested, I could also email you my routines, but they make some assumptions about the underlying tables, particularly the primary key (but it could be modified relatively easy).

>Mark
>
>I'm only selecting one record at a time, the resulting cursor is tied to a form that allows me to edit various user details. The update only works if I select the very first record from the ApplicationUser table. If I select any other record, it will appear in the cursor as you'd expect, although when you perform the tableupdate() it doesn't save any of the changes at all.
>
>I'm beginning to think that it may be an issue with SQL, I'm going to have to tie the code to another DB and see if it works on that.
>
>Regards
>
>Derek