Hmmmm...

Post #59,449 by mmoffitt 10/25/02 3:04:19 PM Reply	Hmmmm... I have no experience w/Delphi/Kylix "bound" controls. However, bound controls only make sense for read (or select) access - just viewing existing data, not altering it. I maintain that anyone who uses a bound control for updating a table hasn't properly secured his/her database. 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. bcnu, Mikem
Post #59,522 by CRConrad 10/25/02 6:40:06 PM Reply	Even better than that! [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. Christian R. Conrad Microsoft is a true reflection of Bill Gates' personality - the sleaziest, most unethical, ugliest little rat's ass the world has seen unto this time. -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=42971\|Andrew Grygus]
Post #59,642 by mmoffitt 10/26/02 5:23:13 PM Reply	Devil's Advocate. >>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
Post #59,653 by CRConrad 10/26/02 7:00:55 PM Reply	Topsy-turvy upside-down argumentation from MikeM (new thread) Created as new thread #59652 titled [link\|/forums/render/content/show?contentid=59652\|Topsy-turvy upside-down argumentation from MikeM] Christian R. Conrad Microsoft is a true reflection of Bill Gates' personality - the sleaziest, most unethical, ugliest little rat's ass the world has seen unto this time. -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=42971\|Andrew Grygus]

Welcome to IWETHEY!