>>What if, for example, there were a way to use RDBMS server data pretty much
>>*as if* it were a local DBase or Paradox table?

I can do that w/ADO Disconnected recordsets. I can also suck data down to a local db, then call the BatchUpdate method and handle all my errors from all the stuff I've done at that point. It's a different approach, but one I've infrequently used. Still, that approach doesn't demand "bound controls".

>>What if, for example, there were a way to use RDBMS server data pretty much
>>*as if* it were a local DBase or Paradox table? Ever considered, for example,
>>actually *using* a local DBase or Paradox table to cache data for each user
>>in, locally on his/her machine?

Considered and (almost always) rejected. I can imagine cases where that might make sense, but I can imagine even more cases where replication would be a better solution.

Here's my point. I've found it easier and cleaner to write sp's, rules, triggers, etc. on the db server and create custom error messages to be passed back to the client apps (be they my own, some one elses or even, GACK, MS Access). My client apps then, become only pretty shells for populating parameters of stored procedures, and handling some generic error trapping code that can just display what the db server said was wrong. I don't see what's wrong with this strategy, moreover, I don't see what bound controls give me for update/insert. Except maybe, if as you say and I can "bind" a text box control to a parameter of a sp_mytable_update stored procedure, then I skip having to write a couple lines of code.

As for using Dbase, I did. Long ago when it owned the market (mid to late 1980's). I was even a ClipperHead (if you know what that was). But Dbase now? I don't think so. It had it's day in the sun and that day passed along time ago. (.DBF, .MDX, .CDX, .NTX, .NDX, blech!)

bcnu,
Mikem