Trial and error? Try VB database access sometime

Post #59,002 by wharris2 10/24/02 12:10:11 AM Reply	Trial and error? Try VB database access sometime Talk about trial and error. Visual Basic (at least earlier versions, who knows what the hell VB.net does) would error out on common conditions and, hell, is finickier than Grandma.
Post #59,093 by mmoffitt 10/24/02 12:32:14 PM Reply	If you use DAO, you deserve what you get. Or Jet, for that matter. Which is why Exchange is such a collosal POS. Around about the time VB4 came out, MS bought this thing from some company in NY that they renamed RDO (remote data objects). That got morphed into ADO. The problems I've had w/ADO stemmed from the MS goo that was being put into RDO (never underestimate MS's ability to "enhance" a product into utter worthlessness) and version incompatabilities (Aside: they shipped ADO w/just about everything and by the time of versions 2.1, 2.1a,b,c 2.2, 2.21, etc, damned near everything broke). But, RDO was solid and ADO (using >= v 2.5) I haven't had any problems with (except when trying to connect to DB2/400 [note: not DB2 UDB]). DAO, OTOH, is a pile of excrement even by MS standards.
Post #59,143 by wharris2 10/24/02 2:26:49 PM Reply	Re: If you use DAO, you deserve what you get. Actually, I was thinking of the even earlier database access - what was that pile of gently steaming dung called?
Post #59,236 by mmoffitt 10/24/02 7:34:48 PM Reply	Stumped me. You talking prior to VB3? VB3 was the first rev of VB I played with to any extent and iirc you used DAO w/it. No?
Post #59,242 by wharris2 10/24/02 7:58:51 PM Reply	Something about bound controls? There was something in VB3 that used "bound controls" or something like that, but I don't remember what it was called (other than four-letter words.) Had a consulting group (read: newbies but we'll claim we're consulting and learn while doing) do a couple of programs with it; they didn't know even about DAO (or is that DOA?) I do understand ADO and its minions are better. But I haven't done enough VB programming to tell if Microsoft has really desanitized the fly-swarming heap of crap its VB database access has been in the past.
Post #59,243 by mmoffitt 10/24/02 8:02:42 PM Reply	OMG! The "Data Control". Only a friggin' moron uses "bound controls". Jesus! I never knew anyone actually billed for that kind of crap. DAO is the object model that the "Data Control" was built on (basically a wrapper for the Jet Engine). Gack! I just realized I'm confessing to more knowledge/experience about this than I'd like to with you guys. <:-O bcnu, Mikem
Post #59,247 by wharris2 10/24/02 8:07:45 PM Reply	Chuckle Company finally realized the path of insanity the project was taking and rewrote the application using... well, I don't know what since I wasn't involved in it (fortunately). Hopefully ADO was available by that time.
Post #59,355 by CRConrad 10/25/02 3:26:48 AM Reply	Clarification/emphasis needed: MikeM rants: OMG! The "Data Control". Only a friggin' moron uses "bound controls". Jesus! I never knew anyone actually billed for that kind of crap. DAO is the object model that the "Data Control" was built on (basically a wrapper for the Jet Engine). That should be, "Only a friggin' moron uses Visual Basic bound controls". Sure, VB is what this discussion is all about -- but, if someone saw this post in isolation, this far down the thread the context may be lost; the condemnation of bound controls looks quite general... Delphi's bound controls work quite nicely, thankyouverymuch. (Whole 'nother object model, and so forth, but the same name 'coz it's basic[Heh! :-]ally the same concept.) 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,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!