No server is an island. In this chapter we have begun to allow the server to be seen and
heard
. Both MAPI and TAPI can be critical to the operation of a reliable and reactive server-based application. The addition of a message pump within the service broadens the ability of the
CPPService
framework to interact with the wide variety of COM APIs beginning to emerge.
Chapter 12 will enable the service framework to reach out even further, via two of the more common client/server communications
methods
: WinSock and named pipes.
Chapter 8
The ODBC API
Prior to Open Database Connectivity (ODBC),
clients
who interacted with data located on a remote server had to use a proprietary API or an embedded SQL code. An example of a proprietary API is the
BTRV
function used to access data stored in Pervasive Software Btrieve. Calls to
BTRV
were identical, semantically, regardless of where the data resided, but the code would have to be recompiled for each client platform and relinked as well. Of course, getting data from other sources required other
methods
.
The more
convenient
option for accessing server data was embedded SQL codeSQL code was embedded in the source program and a precompiler was required to properly set up the SQL calls. This model was acceptable as long as most programs dealt with only a single data source. If you had to access data sources from multiple database
vendors
, you needed multiple versions of a program and you needed to know the
name
of each destination database at compile time.
In the 1980s, the proprietary API and embedded SQL models
began
to fail under the weight of multiple databases and the widespread availability of applications such as Lotus 1-2-3, Microsoft Excel, and Microsoft Access. Users of these PC programs needed to access information from a variety of server-based data sources, and they wanted convenient access from within their favorite productivity applications. Blending data from both PC and mainframe data sources became a necessity.
ODBC was developed to provide client workstations with the ability to attach to databases located on remote servers. Within server-based development, ODBC has recently become a significant force because of the role of Microsoft Windows NT and Windows 2000 in the network operating systems market and the emergence of Windows 2000 Server as a Web host. The
reliance
of most Web servers on convenient data connectivity also has placed new emphasis on ODBC. Furthermore, using ODBC is the primary way to access data from the script-based Active Server Pages provided by Microsoft Internet Information Server (included with Windows 2000 Server).
What ODBC Provides
According to the
Microsoft ODBC 2.0 Programmer's Reference and SDK Guide,
ODBC provides the following:
-
A library of functions that enable you to connect to a database, execute SQL code, and retrieve results
-
A standard SQL syntax
-
A standard set of error codes
-
A standard way to connect and log on to a database
-
A standard representation of data types
The first, second, and fourth provisions in the list are
fairly
straightforward, but the third and fifth are not. Although ODBC provides a standard way of getting to error codes, I would argue that the actual error codes are not standard. I have seen an error message that simply told me the database driver's error database could not be found and then only provided me with an error code. (See Figure 8-1.) A driver from another vendor routinely returns an error message that says, informatively,
"<<error>> Failed to connect to server".
Figure 8-1
Uninformative error dialog generated by an ODBC driver.
Although representing data in a standard way has many benefits, it has a few drawbacks as well. The problem is that the goal is too ambitious. Before getting to examples, let's take a look at a warning in the data types appendix from the current ODBC documentation included with MSDN July 1999:
Important
The tables throughout this appendix are only a guideline and show commonly used
names
, ranges, and limits of SQL data types. A given data source may support only some of the listed data types and the characteristics of the supported data types may
differ
from those listed.
From this previous information, it is unclear what data types are available and what the ranges allowed might be. How can this be
problematic
? Consider a program that copies date and time information from a Microsoft Access database to a Microsoft SQL Server database. The Microsoft SQL Server SMALLDATETIME field type is not identical to the Microsoft Access DATETIME field type; the conversion from the Access type to the SQL Server type will drop seconds and
milliseconds
. If the date and time field is being used to generate a unique key, this data loss will likely cause problems.
Despite the previous warnings, ODBC
generally
works. I will provide sample code that will run on either SQL Server or Access without any change to the object code. The SQL code passed to an ODBC driver can be generated at compile time or at run time, allowing the program to work with dynamically changing data sources. ODBC will often be the only
feasible
option. If you want to create a data-driven Web page in Internet Information Server and you do not want to resort to a custom data interface ISAPI program, ODBC is essential.