Hi Simon,

>Well as I look at the answers I've received, in the first one you said the CursorAdapter does not generate code, but in the help it says exactly the opposite.
>

Sorry, I misunderstood you question "Do CursorAdapters generate clean code?". CursorAdapter does generate DEFAULT Insert/Update/Delete commands, but I always think of them as commands, not like code. Code generation means something different to me, for example, when builder generates some code.

>But now you're going on to say that the TABLEUPDATE() command can call stored procedures?
>

I've said it twice and I can say it again. Commands that CursorAdapter generates are DEFAULT commands, you can alter them either by assigning custom command to InsertCmd/UpdateCmd/DeleteCmd property or by changing command(s) passed to BeforeInsert/BeforeUpdate/BeforeDelete event. Custom command can be any command that the data source is able to handle: UDF call, stored procedure call, ... Now, when TABLEUPDATE() is called for a cursor associated with a CursorAdapter object, TABLEUPDATE() delegates its work to that object, appropriate events are raised and DEFAULT or custom commands are executed thru the data source. Thus, if you set up CursorAdapter to call stored procedures, TABLEUPDATE will call them by means of delegating this work to CursorAdapter. Same true with REQUERY() function, it also delegates its work to CursorAdapter object.

>As I originally started this question with the reasons for using a CursorAdapter over something like a customised class for handling data access(ugh, Access) operations, then I still don't see the benefits.
>

I don't know what your customized class is capable of, but I think it is not integrated with TABLEUPDATE and REQUERY functions. Only you can compare both classes and come up with the answer whether you are going to get any benefits from CursorAdapter. However, in order to make the right decision, you as well have to know what CursorAdapter is capable of. Do you know?

Thanks,
Aleksey.