File: odbintro.html

package info (click to toggle)
gnade 1.5.1-2
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 5,084 kB
  • ctags: 308
  • sloc: ada: 21,567; sh: 3,648; makefile: 843; sql: 378; awk: 29; xml: 9
file content (211 lines) | stat: -rw-r--r-- 5,928 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Introduction to ODBC</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="GNADE User's Guide"
HREF="gnade.html"><LINK
REL="UP"
TITLE="ODBC bindings for Ada 95"
HREF="odbc.html"><LINK
REL="PREVIOUS"
TITLE="ODBC bindings for Ada 95"
HREF="odbc.html"><LINK
REL="NEXT"
TITLE="Using the Ada 95 ODBC Bindings"
HREF="odbcuse.html"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>GNADE User's Guide: GNADE, The GNat Ada Database Environment; Version 1.5.0; Document Revision $Revision: 1.42 $</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="odbc.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="odbcuse.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="ODBCINTRO"
></A
>Chapter 13. Introduction to ODBC</H1
><P
>    The ODBC interface provides an interface between applications and an underlying 
    data base in such a way, that the application code does not depend on the 
    underlying data base. 
    </P
><P
>    The ODBC interface consists of a so called driver manager and the ODBC driver it self. The 
    driver manager (DM) is a library that on one site offers the specified ODBC API to applications. 
    The DM therefore is what you essentially link to your application. But in large parts the 
    DM routines are only stubs. 
    At run time the DM decides which database to access and based on the type of the database which 
    vendors database ODBC driver to load. So basically most DM implementations require that the OS 
    supports dynamic linking and that the database vendors provide the database site of the ODBC 
    drivers as dynamic loadable entity (aka DLL or shared libraries). But the DM does more than just 
    to provide these stubs and the dynamic linking of the corresponding implementations. 
    As ODBC evolves over time, the DM is also responsible to handle the situation that with a new 
    version of ODBC new API entries are defined, but they are not available in a database driver 
    because this driver was developed when an earlier version of ODBC was the rule 
    (for example we now have ODBC 3.52 and the MySQL ODBC driver is written for ODBC 2.5x). So an 
    application might link against an ODBC 3.52 DM and use all the new and hot ODBC entries, 
    although the database used doesn't have them in its ODBC driver. 
    The DM usually reacts in one of two ways:

    <P
></P
><UL
><LI
STYLE="list-style-type: opencircle"
><P
>             it raises an error indicating an unsupported call.
          </P
></LI
><LI
STYLE="list-style-type: opencircle"
><P
>             it emulates the new call by translating it to a previous (maybe deprecated) call or 
             series of calls. Funny enough this happens quite often and the way how to emulate a new 
             call by existing ones is in most cases exactly described in the ODBC spec.
          </P
></LI
></UL
>
    </P
><P
>    The mechanism how to select the right driver is system dependent, but the principal idea is 
    that you have some kind of repository where you associate logical names with configuration 
    information telling the DM the specifics which driver to load. On Win32 this repository can 
    be the registry or so called DSN-files, on UNIX this is mostly an ODBC.INI file containing the 
    information in some structured fashion. 
    The application opens the database by specifying such a logical name and its the task of the
    DM to consult the repository and to dynamically load the right database driver. In this way, 
    a carefully written application can not only be written in a database independent fashion 
    (using the ODBC API), but also the resulting binary can be dynamically configured to use 
    different databases. This is what makes ODBC so successful on Win32 and will make it more and 
    more important also on UNICes. You can write very generic data aware code ranging from 
    applications
    like MS Access that can operate on any database that supports ODBC, to GUI widgets like data 
    grids that you can incorporate into your GUI application and that binds "magically" to nearly 
    any database you want.
    </P
><P
>    The database ODBC driver is typically a sharable object that implements the ODBC interface on 
    the database site and is loaded by the DM. In theory - although quite uncommon - you may link 
    such a driver directly to your application. This will work if your application makes only 
    ODBC calls that are implemented by the ODBC version used when writing the database driver. 
    Your application then is written in a database independent fashion, but the binary is bound 
    to a specific database.
    </P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="odbc.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="gnade.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="odbcuse.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>ODBC bindings for Ada 95</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="odbc.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Using the Ada 95 ODBC Bindings</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>