We help IT Professionals succeed at work.

To use Data Bound controls or not ?

optical asked
Medium Priority
Last Modified: 2010-05-03
From books, DBList, DBCombo and also the List, Combo separately could utilize DAO recordsets.  Which provides more accuracy even though more code is required ? Which provides greater data access speed ?  Which do you prefer ?
Watch Question

In my experience, data controls are evil. <g>  They have the tendency to "snap-back" to the first record in the recordset once you update a record (from what I remember), and what you change in the control directly updates the data (again, from what I remember. There are probably ways of dealing with these behaviors, but I never pursued them--data-bound controls scared me!

One advantage of data-bound controls, though,  is that they require less code.

I've used DAO and RDO and they seem to require the same amount of coding.

But I would recommend RDO for several reasons, the not the least being that RDO seems to be the successor to DAO, it's also faster than both data-bound (which are a dog) and DAO; it allows batch processing as well as asynchronous transactions, and it is event-driven.

Look into it for yourself, run some comparable tests, there's enough information in Books Online to help you decide.


Here are some rambling thoughts. It has been a Monday and I am writing this with a beer in my hand. Pardon any incoherency.

IMHO, in DAO it is a toss-up. If your form is based on one table, you can get some decent performance improvement going unbound (because you can use a table-type recorset), but I typically have only trivial forms which are based on one table. Searching through multiple table-type recordsets is almost always less efficient than using a dynaset on a query with a join. If you have large numbers of users, unbound will help increase the maximum number of effective users. Of course, if you have a large number of users, why are you using DAO?

As for ADO & RDO I definitely prefer working unbound. You can manage your connections much better manually than with data controls.
tomook.... I hear the beer.  It is a Monday indeed.

I agree with the management of your connections.  You always know precisely what's what.

My opinion is, that it depends on your comfort level and the task you are undertaking.

Although I am using DAO in most case now, I had used data control and bounded control for my first couple of years, and I had not experienced significant trouble.  

However, DAO (and RDO) gives you more capbility and flexibility, although it required significant more code.

If you feel more confortable with coding, and have a good idea as how to doing it, by all means use DAO.  If you are relatively new in VB database programming, I would suggest you start with data control, but do pay attention to some of the behaviors of data control.

tomook.... I hear the beer.  It is a Monday indeed.

I agree with the management of your connections.  You always know precisely what's what.
  The data control is an anathema to me. Very difficult to understand its behaviour. I find it
always convenient to use the unbound controls. The flexibilty available easily offsets the
difficulty in coding. Moreover complex insert update and select queries is easier to handle
in the unbound mode.

Id depends on the type of application u are developing.For a 3tier client server application data bound controls are a strict no-no as they take a lot of time to make connection and fetchn data.RDO is better.For stand alone apps.Data bound controls are better.
Data-bound controls completely violate three-tier architecture.

Unlock this solution and get a sample of our free trial.
(No credit card required)
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.