[link|http://z.iwethey.org/forums/render/user?userid=109|MikeM] proclaims:
I have no experience w/Delphi/Kylix "bound" controls.
Yeah, I figured as much.
So, if that's all the clarification you're going to give, I supose we'll have to settle for that.
However, bound controls only make sense for read (or select) access - just viewing existing data, not altering it.
Depends -- what's wrong with, for example, using bound controls to update records in a local DBase or Paradox table, where your app is guaranteed to be the only one to access the table at any given time?
I maintain that anyone who uses a bound control for updating a table hasn't properly secured his/her database.
Yeah, you do... "maintain", that is -- regardless of the fact that you just confessed your complete ignorance about at least one kind of bound controls. Do you always pronounce such cut-and-dried opinions on stuff you've just admitted to not knowing anything about?
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? I *know* that works -- I've *done* it! (This was before the dbExpress architecture was introduced.) (And in the process, I made a TDBGrid look almost like a damn spreadsheet, by going through and updating the local Pdx table on-the-fly... :-)
That's also pretty much how Borland used to do it... (Though admittedly that first attempt was somewhat flaky and resource-intensive in the beginning; that's why I rolled my own, simpler, variant.) Only, nowadays they've replaced TCachedDataSet with the even better TClientDataSet (see more below).
Unless Delphi can bind a control to a parameter of a stored procedure, using bound controls for anything but displaying data is not a good idea, imnsho.
Delphi can do much better -- it can bind a control to a TClientDataSet, which in turn is de-cached back onto the server (when you call the
ApplyUpdates method) as a parameter of a stored procedure (though more normally as one parameter of a parameterized
INSERT statement) -- or pretty much any way you want to handle it, in a
BeforeUpdateRecord event handler.
This [link|http://bdn.borland.com/article/images/29106/migrating_bde_applications_to_dbexpress.pdf|white paper by Bill Todd] really discusses the migration of BDE-based applications to dbExpress, but in the process it becomes maybe the best intermediate-level explanation of that new architecture (also called "provide/resolve") I've seen. "Recommended", as JerryP would say.