[ Pobierz całość w formacie PDF ]
.By passing ODBC SQL to an ODBCdriver, the application can communicate with the database using SQL.Because there are manydifferent flavors of SQL, ODBC provides a single flavor that would be translated into a flavor that thedatabase could read.NOTEYou might have heard that an ODBC driver is Level X-compliant as relatedto the API.What does this mean? There are three levels of compliance:Core Level-All drivers must support this level.Must be able to supportconnections, SQL statement preparation and execution, data setmanagement, and transaction management.Level 1-Must support all core-level compliance, as well as dialog-basedconnectivity, and be able to obtain driver/datasource information, whichincludes advanced connections using get and set options.Level 2-Must support all the previous levels, plus the capability to list andsearch the datasource connections, and advanced query mechanisms andhave support for scrollable cursors, among other things.Figure 14.1 : The ODBC architecture overview.The ODBC Driver AdministratorThe Driver Administrator is a Control Panel applet responsible for defining the ODBC data sources.Adata source is simply the connection definition to a specific database.The connection definitioncontains information about the type of database, as well as the pertinent location information for thedatabase.It then assigns a common name, called the Data Source Name (DSN), to the definition.TheODBC Driver Manager and drivers use the name as an index into the data source table to find thedatabase-specific information.Refer to Day 2, "Tools for Database Development in Visual C++ Developer Studio," for a descriptionof the steps to define DSNs.The ODBC Driver ManagerThe ODBC Driver Manager is a set of functions that receives requests from the application andmanages the subsequent driver actions for those requests.The primary functions of the DriverManager are to load and unload database drivers and pass function calls to the driver.You might bethinking that this is a little bit of overkill.Why not just call the driver directly? Wouldn't it be faster?Just imagine, however, if the Driver Manager didn't exist, and your application was responsible forloading, unloading, and maintaining driver connections.Your application would be responsible forevery possible driver configuration available, including the data source definitions.(Registryprogramming, anyone?) The Driver Manager makes the application developer's life easy, bycompartmentalizing this functionality.If you look a little closer at the Driver Manager, you see that it does perform some processing relatedto your application's requests.It implements some of the functions of the ODBC API.These includeSQLDataSources, SQLDrivers, and SQLGetFunctions.It also performs some basic errorchecking, function call ordering, checking for null pointers, and validating of function arguments andparameters.NOTENote that the ODBC API calls start with SQL.There is good reason for this.The ODBC API communicates through the SQL database interface insteadof calling the database's lower layer.This is done primarily to add somelevel of consistency and standardization.ODBC does this by mappingODBC SQL to the database driver's specific SQL standard.Hence, thenaming convention for ODBC API function calls.When the Driver Manager loads a driver, it stores the address of each function call in the driver andthen tells the driver to connect to the data source.The application specifies which data source toconnect to, using the data source name.The Driver Manager searches the DSN definition file for theparticular driver to load.When the application is done, it tells the Driver Manager to disconnect(SQLDisconnect).The Driver Manager in turn hands this to the connected driver, whichdisconnects from the data source.The Driver Manager will unload the driver from memory only whenthe application frees the connection.The driver is kept in memory in case the application developerdecides he needs further access.The ODBC DriverTo adequately discuss every aspect of developing ODBC drivers would require another book.However, a cursory discussion is warranted.An ODBC driver must perform the following:Connecting to and disconnecting from the data source.Error checking not performed by the Driver Manager.Transaction management.Submitting SQL statements.This involves transposing the ODBC SQL to the SQL "speak" ofthe database that is supported.Processing data.A driver can be defined as one of two types.A file-based driver accesses the physical data directly.ADBMS-based driver doesn't access the data directly but performs SQL functions on another wrapper.This wrapper is referred to as an engine.The database engine for Microsoft Access is the Jet engine.Programmatic Sequence for the ODBC APINow that I've discussed the architecture of the ODBC specification, let's take a look at how to developan application by using the ODBC API.NOTEAlthough this section introduces certain steps in developing an ODBCapplication, it isn't intended to be a complete reference.Many ODBCprogramming references are available that provide in-depth discussionsabout the API function calls.Before I discuss the API function calls, let's make some sense out of processing a data request.Firstyou have to know where the data is (data source definition).Then you have to connect to it.After youare connected, you need to ask the data source for information.After the information is in hand, youprocess it and in most cases hand it back to the data source for safe keeping.When you are finished,you disconnect from the data source.Figure 14.2 : The ODBC programmatic flow chart.Step 1: Connect to a Data SourceFirst you have to acquire an environment handle.Do this by calling SQLAllocHandle.At this pointyou might be asking what an environment handle is.A handle is nothing more than a pointer to aspecial structure.The environment mentioned here is generally considered the system and data sourceinformation that the Driver Manager needs to store for the driver.You might also be asking why theDriver Manager does this, not the driver.Recall that you have not connected yet, and therefore theDriver Manager doesn't know what driver you will be using and will hold this information until it isneeded.Some applications might need to connect to multiple databases.If the Driver Manager did notexist, the application would have to keep track of all the environment handles.SQLHENV envHandle1;SQLAllocHandle(SQL_HANDLE_ENV,SQL_NULL_HANDLE, &envHandle1);After the Environment Handle is allocated, the application must then determine the attributes for thehandle.The most important of these attributes is the ODBC version attribute(SQL_ATTR_ODBC_VERSION).Different versions of ODBC support different SQL statements andparameters.In some cases, it is important to determine the ODBC version that the driver supports andto know the differences.Step 2: Allocate a Statement HandleYou can think of a statement in ODBC as being a SQL statement.As discussed earlier, ODBCcommunicates with the SQL interface to the database.The Driver Manager maps the ODBC SQL tothe driver's SQL.However, a statement also carries attributes with it that define it in the context of theconnection to the data source.This includes, but is certainly not limited to, the resultsets that thestatement creates.Some statements require specific parameters in order to execute.These parametersare also considered attributes of the statement.Therefore, each statement has a handle that points to astructure that defines all the attributes of the statement.This handle also assists the driver in keepingtrack of the statements, because a multitude of statements can be associated with a connection.Statement handles are defined and allocated similarly to the environment handle
[ Pobierz całość w formacie PDF ]