Sure -- I was going to, anyway, but...
...then I wasn't sure if it were smart to take the risk of alienating you from trying Kylix like you said, by insisting that you were wrong on bound controls.
(Which, of course, you still are! :-)
One problem w/bound controls is the following:
1 form w/10 "bound" textboxes (or textareas or whatever they're called in Delphi) to columns in say, a Sql Server table.
["DBEdit" controls, actually, but go on.]
When I change a value in those textboxes (and move the focus elsewhere), VB will spawn a new temp stored procedure to update the value I just changed (that's create, compile, execute on the server). Then I navigate to the next textbox and change its value - another temp sp is created, compiled, executed, then the next textbox, etc.
Aaargh -- that's the STUPIDEST thing I've ever heard!!!
Are you *sure* it wasn't Bryce -- or, even worse, Norm -- who created the VB implementation of bound controls?!?
So, if I use "bound" controls, (and let's say I'm not using disconnected recordsets - for the sake of argument), I will create 10 separate temporary stored procedures, have 10 separate compilations and 10 separate executions (and these temp sp's are erased after they are executed) to update 1 row of my table.
One procedure *per field*, you say -- not even per *record*? Ho-lee SHEE-IT! No wonder people are negative to the whole concept; if they think THAT is the only way to do it... I can, as so often before, only marvel at Microsoft's complete and utter incompetence.
Oh well, anyway: ... Dang, I don't know how to say this without having a small history lecture first. Where to begin? OK: If you're doing this using Delphi 5 or Kylix 1 or newer, you probably *would* be using "disconnected recordsets", in the form of TClientDataset; if you're using Delphi 7 or Kylix 3, then you ARE doing so, because the new SQL driver architecture ("db express") doesn't really work without it; it only gives you unidirectional read-only cursors. But, even in the bad old days of Cached Updates and TSqlUPdate -- on Delphi 3, that is, ~1997 -- *you* got to write the exact SQL Insert, Delete, and Update statements that were executed *recordwise*, stepping through the whole record set one row at a time when you called ApplyUpdates.
As opposed to using un-bound controls where I use one stored procedure, server resident, which gets compiled the first time its called and then is on the server for everyone to use in a compiled state (at least until the server is booted again).
I take it the VB db-architecture doesn't even have separate TStoredProc objects, then...? [Shakes head in sorrow]
VB does this regardless of back-end. I'm interested to see if Delphi/Kylix does the same thing. I'd bet it does, 'cuz if it doesn't you'd run the risk of losing the update if the user changed one value and then exited the app.
Muahahahahahaha!!!
No, my friend, it most certainly DOES NOT do that! (And never has, AFAIK.)
I mean, heck, even the naive TSQLTable component in Delphi *1* -- A.D. 1994! -- never was THAT stupid, as to try and send something to the server before you scrolled off the current *record*.
Oh sure, you *could* miss some pending updates in a Delphi app -- if you CRASH it before it gets around to applying its updates back to the server... Or, OK, if you haven't coded a simple check-for-pending-updates into the Close event of your main window, or some other such suitable event. (But you'd have to be a pretty *bad* coder to miss doing that, IMnshO.)
And ISTR, if you closed the oldest kind of app, using the TSQLTable, you didn't have to check even that possible single row for pending updates; the TSQLTable object class itself had that check built-in. (But don't quote me on that, 'coz I can't remember for sure any more. I *has* been a while, after all... :-)
I just don't see how you can get around this performance issue using bound controls. But, the criticism that I haven't seen Delphi's way is valid, hence my planned dabbling with Kylix.
Phew...
Well, thank Ghu for that.
As will you.
