>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
But I agree, a recordset as a datasource for a grid would be a great addition but I imagine it'd be a major PITA to manage the updates depending on the type of recordset, whether it's batch updates, et al.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

I don't know, John. Would it be that different than what we have now with, say, remote views? The developer makes a decision about the type of data buffering, and binds the view to the grid. Then, it is up to the developer to issue an approriate update when required, to handle transactions, etc. The table/cursor/view-bound grid isn't really "in charge" of the updating of data. In fact, you can bind a grid to a read-only cursor - you just can't update it. A static recordset object could be handled the same way.

Decisions about server-side vs. client-side business could prove tricky, but no more so, to my mind, than it is currently for most ADO processes.

The biggest problem I can see would be with Shape-constructed recordsets, but I would have no problem with a sub-table field simply being ignored by the grid.

Or am I missing something else you had in mind as an issue?