History of VB [AVDF Article]

Image Map of Navigational Panel to Home / Contents / Search

Visual Basic 4.0: The SQL

History of Visual Basic

Visual Basic started out with the ill fated Omega project at Microsoft. Omega was supposed to be a database that would remove the dBase and Paradox strangle hold that existed in 1988/89. It never really got anywhere but Bill very much liked the programming language and had the guys go and work on it exclusively. This developed into the Thunder project that then gave birth to Visual Basic. Thunder was a very apt name for it, as VB came onto the development scene with a boom. It showed for the first time what Rapid Application Development (RAD) really was. (I don't know if you remember the first ads that were placed about its speed of development - they showed two applications developed side by side and how long it took. My C based application was beaten to completion by about 200% by the VB version.)

Whilst the final preparations for the release version were under way, the QuickSilver team converted to Cirrus and started work on what was to become Microsoft Access. By the time version 3.0 of Visual Basic was ready to ship Access was the undisputed king of the desktop database market, so it was natural for Microsoft to include the Access data engine into Visual Basic. Prior to that, Visual Basic could only access databases through ODBC or proprietary DLLs.

ODBC

ODBC stands for the Open Database Connectivity Standard and was backed by Microsoft and a number of other development tool vendors. ODBC consists of a number of APIs in the Windows environment and allows the developer to call a standard API instead of a proprietary one for a given SQL Database. An example of this would be an application that needed to talk to Oracle as well as SQLServer. To talk to oracle they would talk via SQL*NET - to get to SQLServer the method would be DB-Lib. This created the problem where developers couldn't generate economies of scale because they had to hand craft code for each platform. ODBC tried to solve this but generated its own problems as well. With the requirement to call an API, RAD developers found it limiting. They wanted a single easy to use entity set that provided them with a great deal of high level functionality. This requirement in the Visual Basic market was met by the Access data engine, or as it was more correctly known, the Jet engine.

JET

Jet was the underlying data access technology that came from the cirrus project. A lot of people tend to confuse the Jet engine with the Access environment that was layered on top of it. The Jet engine provided high level database functionality such as RecordSets, Tables, Databases and Queries. This functionality was easy to use and easy to link into the graphical front ends of the Visual Basic development environment. Without needing to create a complex ODBC call set I could ask Jet to execute a query, retrieve the rows, sort them and allow me access.

However there was, to quote Paul Keating, no such thing as a free lunch. The model of the objects was designed to perform a lot of processing that wasn't really required in the client/server world (remember that Jet grew from the requirement to produce a top flight desktop database). The majority of Jet users were Access users and so they never really felt the worst effects of these factors. The VB development community, though, was more than willing to share these problems with us.

Problems With Previous Versions of Visual Basic

The worst problem with Visual Basic 3.0 and Jet was probably the lag in retrieving the rows from a query. Jet, at the time, ran all queries synchronously (and it still does to an extent in the Data Access Objects model). That meant that until a query completed all processing, Jet would not return query control to the VB application. This is technically known as a bad thing, especially if you have just sent it off for a million rows by mistake. Also the Jet engine would spend time performing useful tasks like background population which is not really required in the Get/Fetch world of client/server. The import of that is that rather than one medium hit on the server you would have the system continually placing small demands on it. Some organisations found that this was crippling to their network performance (an example was Telstra who found that Oracle servers and background population really didn't get along). Jet also did some funky stuff, with the handling of indexes for local and remote joins, that caused problems where there was a small table locally and a large table remotely.

It's unfortunate that ODBC received a lot of bad press for performance issues when really it was the Jet engine that caused most of the delays. Under Jet 1.0 and VB 3.0 the best way to optimise client server was to bypass Jet and go to ODBC directly. Fortunately this has changed under Visual Basic 4.0.

[HOME] [TABLE OF CONTENTS] [SEARCH]