2 BetaDBC Basics

Generally speaking, there are two ways of programming to a relational database, namely using

• Embedded SQL. Using this approach SQL statements are embedded in a host language. Using a Database Management System (DBMS) specific precompiler, the application program is precompiled, transforming statements containing shared variables (variables shared by the DBMS and the application program) into DBMS library calls. After compilation the program is linked with the DBMS' runtime library.
• Call Level Interfaces (CLIs). These are libraries of functions. The functions are the native application programming interface of the DBMS or calls to it. In this way, a precompiler is not needed.

Both approaches suffer from some problems although standards have been proposed: Embedded SQL ties a program to a specific DBMS meaning that at least a new compilation will have to be made if a new DBMS is to be used. CLIs are hard to learn and often contain a lot of DBMS specific functions.

BetaDBC combines these two approaches in such a way that although shared variables may be used a precompiler is not needed and furthermore all DBMS may be treated alike. In order to achieve this BetaDBC currently builds upon and extends Open DataBase Connectivity (ODBC [Geiger 95])

This means that the architecture of a typical BetaDBC application may be outlined as below:

A BETA application typically connects to a DBMS via BetaDBC, calls BetaDBC functions, processes results and disconnects. The driver manager loads and unloads drivers as requested by applications, and processes function calls before sending them to a driver. The driver then processes the functions calls, submits SQL requests to data sources and returns results. Data sources encapsulate the data in form of tables that a user wants to access together with an associated operating system, DBMS, and network platform (if applicable) used to access the DBMS.

Details on how to create data sources and use BetaDBC in this environment will be given below.