So, a bug in either the CA or in ADO is the only alternative? You are 100% sure that the recordset is properly configured? See if thread #898887 can help.

There is always an option to use ADODB.Command object to modify the backend, CursorAdapter supports this too.

Thanks,
Aleksey.

>Well, the problem seemed to be a bug in either the CA or in ADO. Some KB articles on ADO 2.7 indicated problems in situations the same as mine, however I have 2.8 installed. Maybe it was not fixed. I could update the underlying table only when the cursor created by the CA was not the product of a join. So I opened two tables, one to help with letting the user edit the data and one to actually get the data updated. Works fine, though it's a bit kludgey.
>
>>Hi Russell,
>>
>>When you are using “ADO” data source, Update/Insert/Delete commands are not generated and are not used unless corresponding …CmdDataSource property is set to ADODB.Command object and …CmdDataSourceType is set to “ADO”. When commands are not used, all modifications go through the Recordset object and you should make sure that the Recordset is configured in a way that it is capable to perform required modifications.
>>
>>Thanks,
>>Aleksey.