IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New 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]
New 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


New 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]
New 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

New 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]
     MS Office 11 to have XML document format - (admin) - (26)
         This is getting too easy - (drewk) - (10)
             Re: This is getting too easy - (admin) - (1)
                 Like I said, strictly an import filter - (drewk)
             Last I heard, - (Andrew Grygus) - (1)
                 Just curious... - (inthane-chan)
             Besides, XML is a framework - (wharris2) - (5)
                 msoft_format_special - (imric) - (4)
                     Re: msoft_format_special - (jake123) - (2)
                         No guarantee at all - (drewk)
                         Well, hold on there a second... - (jb4)
                     Reading some of the other comments, - (wharris2)
         Ugh - die XML, die! -NT - (deSitter) - (1)
             Seconded. -NT - (mmoffitt)
         Don't trust published MS formats - (warmachine) - (12)
             Trial and error? Try VB database access sometime - (wharris2) - (11)
                 If you use DAO, you deserve what you get. - (mmoffitt) - (10)
                     Re: If you use DAO, you deserve what you get. - (wharris2) - (9)
                         Stumped me. - (mmoffitt) - (8)
                             Something about bound controls? - (wharris2) - (7)
                                 OMG! The "Data Control". - (mmoffitt) - (6)
                                     Chuckle - (wharris2)
                                     Clarification/emphasis needed: - (CRConrad) - (4)
                                         Hmmmm... - (mmoffitt) - (3)
                                             Even better than that! - (CRConrad) - (2)
                                                 Devil's Advocate. - (mmoffitt) - (1)
                                                     Topsy-turvy upside-down argumentation from MikeM (new thread) - (CRConrad)

I'm sure when this came out, it was better than whatever else was out. Want to play chess with me, son? No way, Dad.
56 ms