
Data-Bound Vs. Non-Data-Bound Controls
I do suggest searching this newsgroups themselves. This discussion has been
in here many many times. I am one who believes that databound controls are
for those who really do not know how to do the work themselves. I do
apologize but I have had this discussion myself many times and just cannot
take the time to go into the whole reasoning why. I just wanted to say that
I agree with your devleopers who say stay away from them and also to tell
you to simply search these newsgroups. You will find many examples from
both sides of the fence. One final note, I have not used a databound
control in 3 years and my programs always out perform those written by other
developers using them. My applications also are far easier to maintain and
add-on to with future requirements (BIG KEY BENIFIT).
-Clint LaFever
http://www.saic.com
http://lafever.iscool.net (personal)
Quote:
>We've got a technical debate on our development team about using data-bound
>controls.
>The back-end is SQL7 and we're using VB6 and ADO to connect to it. One
>group insists that data-bound controls are terrible. They want to do
>everything by hand (i.e. code an ADO connection, generate a recordset, step
>through each field for the current record, and then do manual assignments
>i.e. field1.text = recordset.field(1).value). The other group thinks this
>is tedious and a waste of valuable time (we've got a tight deadline).
>They're fine with coding a connection & generating a recordset, but feel it
>would be wiser to bind the fields to the recordset and have that binding
>take care of populating the the fields with data.
>Some of the arguements I heard against this include a significant increase
>in the number of open connections (i.e. 1 connection per data-bound
>control), buggy implementations of the controls, & slower performance than
>hand-coding.
>I've searched MSDN On-Line for several hours and it appears that they think
>ADO and data-bound controls are ok to use in any application. Nothing I've
>read states that in some many words, however, the tone of the articles
imply
>it. We've got a tight deadline and need to resolve this ASAP. Does anyone
>know of any articles that examine this issue in detail or has anyone had
any
>experience with this issue? I'm looking for a neutral 3rd party
>source/expert that can help me put this issue to rest so we can get on with
>the development effort.
>Thanks in advance.
>Gerry Baldwin
>Universal Data Solutions