Take a quick look at Visual Basic related newsgroups and you'll see them peppered with questions about how to bind this piece of data to that control and so forth. The good souls that inhabit this virtual space patiently answer these questions without actually understanding that while they intentions are good, the road to hell is paved with them.

Visual Basic enabled a lot of people to take a quick six-month community college VB course and call themselves programmers. Egged on by the salaries and vagaries of the dot-com era, they go on job interviews where they extol the virtues of the address book application they've written as their final assignment. Of course, it is almost next to impossible to go from a lamen to a real programmer in such a short amount of time, regardless of how brilliant the instructor was. Plus, given the short period of time and the goal of making a real programmer, the instructors are forced to teach something that is easily understood and can somewhat stick. So, here is what students are taught in six month VB course. First, the teacher drops a couple of controls on the form and shows how "easy" programming in VB really is. Second, they go over language constructs like loops, operators, etc… This in itself is kind of difficult for a first time "programmer". Then, a quick intro into database concepts, nothing really relational, just one, maybe two tables in Access. By this time, you are in the second part of the semester. Time to connect the dots. So how do we connect the database to the VB app. Well, let's drop a data control on the form, visually bind it to various text boxes and have the users press the "back", "next", "first", "last" buttons to get around the recordset. Voila, you are a programmer.

Better yet, if the course is taught in VB6 (instead of VB5 or VB4), will connect the dots using the Data Environment - set up the connection, add a command or two and then drag this beautiful creation onto the form. DE will even create all the necessary textboxes for you. Another scenario for the class is to build a web site using Web Classes. Yoo hoo, so now you are not only a programmer, you are a web developer. The title may overshadow the fact that you have no experience and have trouble getting around MS Word, much less troubleshoot IIS problems. Is this the student's fault? No. The problem is with the course. Is this the student's problem? Absolutely.

So why is Data Binding, Data Environment and various associated wizards so evil? Well, they limit you - the programmer. They prevent you from becoming better, making more money and getting promotions. You don't know what happens behind the scenes, so when something goes wrong, you are so lost. Also, Data Binding locks you in - when you have to go beyond its abilities (which happens in all but most trivial apps), it is incredibly difficult to break through its limits.

So what are the practical problems you'll encounter with Data Binding? The first one you are likely to run into very quickly is the inability to exercise data concurency control. Say you have 2 users accessing the same row of data. This is difficult enough to control with ADO - with Data Binding it is nearly impossible. The second, much more difficult problem to resolve, you'll run into later, when the product has already been designed and written. This predicament is the inability of the data binding engine to adjust itself to your database situation. The data binding engine does not know where your database is, whether the pipe the data is travelling through is high or low bandwidth. It does not know how many records to cache or to get just the fields the application needs at this particular point. The third problem is a killer: your fellow developers will look down on you, much as the RDBMS developers (rightly or wrongly) look down upon Access developers. Data Binding, as Jesse "Body" Ventura points out, is a crutch the for weak-minded. The faster you abandon Data Binding, the faster you will become a true programmer.

I advise you to learn ADO (or ADO.NET) - there are a zillion books on the topic, including some on our site. Consider this, no successful programmer I know of uses Data Binding or Data Environment for any apps, other than most trivial.

Data Binding is also part of the reason why VB earned a somewhat deserved reputation for a toy language. The fact is that the IDE allows toy programmers write toy code, thus resulting in toy apps. And even though VB.NET is a brand-spanking new language with very little in common with classic VB, it will probably also carry the same mantle. While VB.NET forces to write at least a little bit of code and its Data Binding techniques are only that in name (i.e. much different from VB6), it still allows one to drag and drop things and to create a quickie app without writing much code at all.

Anyway, bottom line, drop Data Binding, learn ADO.