When I first received Visual Basic 1, I had distinctly mixed emotions. I had just written my first Windows application using C, and the learning curve had been painful. I can’t tell you how satisfying it was the first time I got a program to compile, run, and display a basic window. It had taken me a week to grasp the idea of a message loop, so just to see a window appear on the screen was bliss. I expanded this program and eventually worked out how to add text boxes, lists, and buttons. However, it was hard work; I just couldn’t see how I was ever going to be as productive under Windows as I had been working in proprietary languages on minicomputers. All this work and I still hadn’t read a single character from a database!
So as you might imagine, when I first installed Visual Basic 1 and worked through the calculator sample program, I couldn’t believe my luck. Here was an ideal tool for building Windows applications. I could forget about all that message-loop stuff and concentrate on writing the application. The user interface became a trivial problem. (Actually it didn’t, but that’s another story.) I could stop worrying about things like what to do with a WM_PAINT message—and get back to building commercial systems, which is what I’m paid to do.
However, there was one problem with this initial version of Visual Basic—it had no database support. And at that time there were few independent Application Programming Interfaces (APIs) available, certainly none for the proprietary database management systems I was using.
Visual Basic 2 was a little more helpful. It shipped with a new specification called Open Database Connectivity (ODBC) and sample programs that showed how to use it. However, the ODBC API was quite complex to use, and it meant I had to find a driver for my data source. There wasn’t one. So I still had the problem of finding a way to get at my data.
Then came what I can only describe as a revolution. Microsoft released version 1 of Access, which included not only built-in support for desktop databases such as dBASE and Microsoft FoxPro but also support for ODBC data sources. This feature made Microsoft Access an instant winner. Its popularity had a dramatic effect on database management system (DBMS) suppliers. DBMS vendors and third-party vendors began rapidly producing database drivers. The vendors were helped in this effort by their not having to build an ODBC driver that could support the full range of the ODBC API in order to be compatible with Access. No major DBMS vendor wanted to be the only one whose product was not accessible via Access. Client/server access became something that anyone could achieve with a few clicks of a mouse button.
Microsoft Access also included two features that were even more important to Visual Basic 3 users—Data Access Objects (DAO) and Microsoft Jet. The Jet engine, the driving force behind Access, had the ability to give even quite weak ODBC drivers the appearance of a richly functional data source. And Jet was easy to use too. The advent of bound data controls gave Visual Basic a functionality that was similar to Access and also made database access much easier.
Note Some people believe that Jet is an acronym for “joint engine technology.” The truth is that it doesn’t actually stand for anything; it’s just a play on the words “jet engine.”
As time went by, however, corporate developers found that Jet, although flexible, got in the way sometimes, and then performance wasn’t as good as it might have been. With Visual Basic 4, we saw the release of remote data objects (RDO), which provided a much tighter link to the underlying ODBC API than Jet and DAO. Consequently, it was possible to get performance improvements that were previously possible only when using the ODBC API directly.
Now, with Microsoft Visual Basic 5, we are seeing yet more data access options. OLE DB provides access to unstructured data such as e-mail messages and word processing documents. ActiveX (formerly OCX, the OLE version of VBX—the Visual Basic Extension technology) and Distributed Component Object Model (DCOM) can provide Internet access to corporate data. A new version of ODBC (version 3) provides even more functionality than earlier versions; exploiting this expanded functionality can provide more of those all-important commodities, performance and flexibility. Remember, as well, that proprietary APIs are still available for many data sources. The Bulk Copy Program (BCP), for example, is a utility supplied with Microsoft SQL Server that can still be the quickest way to get data into or out of a SQL Server database.