Åbn databaseforbindelse - Open Database Connectivity

I computing er Open Database Connectivity ( ODBC ) en standard applikationsprogrammeringsinterface (API) til adgang til databasesystemer (DBMS). Designerne af ODBC havde til formål at gøre det uafhængigt af databasesystemer og operativsystemer . En applikation skrevet ved hjælp af ODBC kan portes til andre platforme, både på klient- og serversiden, med få ændringer i dataadgangskoden.

ODBC opnår DBMS -uafhængighed ved at bruge en ODBC -driver som et oversættelseslag mellem applikationen og DBMS. Applikationen bruger ODBC -funktioner via en ODBC -drivermanager, som den er knyttet til, og driveren sender forespørgslen til DBMS. En ODBC-driver kan betragtes som analog med en printerdriver eller en anden driver, der giver et standard sæt funktioner, som programmet kan bruge, og implementerer DBMS-specifik funktionalitet. Et program, der kan bruge ODBC, omtales som "ODBC-kompatibelt". Enhver ODBC-kompatibel applikation kan få adgang til ethvert DBMS, som en driver er installeret til. Der findes drivere til alle større DBMS'er, mange andre datakilder som f.eks. Adressebogssystemer og Microsoft Excel og endda til tekst- eller kommaseparerede værdier (CSV) -filer.

ODBC blev oprindeligt udviklet af Microsoft og Simba Technologies i begyndelsen af ​​1990'erne og blev grundlaget for Call Level Interface (CLI) standardiseret af SQL Access Group i feltet Unix og mainframe . ODBC beholdt flere funktioner, der blev fjernet som en del af CLI -indsatsen. Fuld ODBC blev senere portet tilbage til disse platforme og blev en de facto standard betydeligt bedre kendt end CLI. CLI forbliver lig med ODBC, og applikationer kan portes fra den ene platform til den anden med få ændringer.

Historie

Inden ODBC

Indførelsen af ​​den mainframe -baserede relationsdatabase i løbet af 1970'erne førte til en spredning af dataadgangsmetoder. Generelt opererede disse systemer sammen med en simpel kommandoprocessor, der tillod brugere at indtaste engelsklignende kommandoer og modtage output. De mest kendte eksempler er SQL fra IBM og QUEL fra Ingres- projektet. Disse systemer tillader muligvis andre applikationer at få adgang til dataene direkte, og dem, der gjorde brug af en lang række metoder. Indførelsen af SQL havde til formål at løse problemet med sprogstandardisering , selvom der stadig var betydelige forskelle i implementeringen.

Da SQL sproget havde kun rudimentære programmering funktioner, brugerne ofte ønsket at bruge SQL inden for et program skrevet i et andet sprog, siger Fortran eller C . Dette førte til konceptet Embedded SQL , som gjorde det muligt at integrere SQL -kode på et andet sprog. For eksempel kunne en SQL -sætning som indsættes som tekst i C -kildekoden, og under kompilering ville den blive konverteret til et brugerdefineret format, der direkte kaldte en funktion i et bibliotek, der ville sende sætningen til SQL -systemet. Resultater, der returneres fra udsagnene, vil blive fortolket tilbage i C -dataformater som f.eks. Brug af lignende bibliotekskode. SELECT * FROM citychar *

Der var flere problemer med Embedded SQL -tilgangen. Ligesom de forskellige SQL -varianter varierede de integrerede SQL'er, der brugte dem, meget, ikke kun fra platform til platform, men endda på tværs af sprog på en platform - et system, der tillod opkald til IBM 's DB2, ville se meget anderledes ud end et, der kaldte til deres egen SQL/DS . Et andet centralt problem for det integrerede SQL -koncept var, at SQL -koden kun kunne ændres i programmets kildekode, så selv små ændringer i forespørgslen krævede en betydelig programmeringsindsats for at ændre. SQL-markedet omtalte dette som statisk SQL , kontra dynamisk SQL, som til enhver tid kunne ændres, f.eks. Kommandolinjegrænsefladerne, der leveres med næsten alle SQL-systemer, eller en programmeringsgrænseflade, der forlod SQL som ren tekst, indtil den blev kaldt . Dynamiske SQL -systemer blev et stort fokus for SQL -leverandører i løbet af 1980'erne.

Ældre mainframe-databaser og de nyere mikrocomputerbaserede systemer, der var baseret på dem, havde generelt ikke en SQL-lignende kommandoprocessor mellem brugeren og databasemotoren. I stedet fik dataene direkte adgang til programmet - et programmeringsbibliotek i tilfælde af store mainframe -systemer eller en kommandolinjegrænseflade eller interaktive formularer i tilfælde af dBASE og lignende applikationer. Data fra dBASE kunne generelt ikke tilgås direkte af andre programmer, der kører på maskinen. Disse programmer får muligvis adgang til disse data, ofte via biblioteker, men det fungerer ikke med nogen anden databasemotor eller endda forskellige databaser i den samme motor. Faktisk var alle sådanne systemer statiske, hvilket gav betydelige problemer.

Tidlige bestræbelser

I midten af ​​1980'erne førte den hurtige forbedring af mikrocomputere og især introduktionen af ​​den grafiske brugergrænseflade og datarige applikationsprogrammer som Lotus 1-2-3 til en stigende interesse for at bruge pc'er som den foretrukne platform på klientsiden i klient -server -computing. Under denne model ville store mainframes og minicomputere primært blive brugt til at levere data over lokalnetværk til mikrocomputere, der ville fortolke, vise og manipulere disse data. For at denne model kunne fungere, var en datatilgangsstandard et krav - i mainframe -feltet var det meget sandsynligt, at alle computere i en butik var fra en leverandør, og klienter var computerterminaler, der talte direkte til dem, men i mikrofeltet var der var ingen sådan standardisering, og enhver klient har muligvis adgang til enhver server ved hjælp af ethvert netværkssystem.

I slutningen af ​​1980'erne var der flere bestræbelser på at få et abstraktionslag til dette formål. Nogle af disse var mainframe -relaterede, designet til at tillade programmer, der kører på disse maskiner, at oversætte mellem forskellige SQL'er og give en enkelt fælles grænseflade, som derefter kunne kaldes af andre mainframe- eller mikrocomputerprogrammer. Disse løsninger omfattede IBMs Distributed Relational Database Architecture ( DRDA ) og Apple Computer 's Data Access sprog . Meget mere almindeligt var imidlertid systemer, der udelukkende kørte på mikrocomputere, inklusive en komplet protokolstak, der inkluderede enhver nødvendig netværks- eller filoversættelsesstøtte.

En af de tidlige eksempler på et sådant system var Lotus Development 's DataLens , oprindeligt kendt som Blueprint. Blueprint, udviklet til 1-2-3, understøttede en række datakilder, herunder SQL/DS, DB2, FOCUS og en række lignende mainframe-systemer samt mikrocomputersystemer som dBase og de tidlige Microsoft/Ashton-Tate-bestræbelser, der til sidst ville udvikle sig til Microsoft SQL Server . I modsætning til den senere ODBC var Blueprint et rent kodebaseret system, der manglede noget, der nærmede sig et kommandosprog som SQL. I stedet brugte programmører datastrukturer til at gemme forespørgselsoplysningerne og konstruerede en forespørgsel ved at koble mange af disse strukturer sammen. Lotus omtalte disse sammensatte strukturer som forespørgselstræer .

Omtrent på samme tid arbejdede et brancheteam med medlemmer fra Sybase (Tom Haggin), Tandem Computers ( Jim Gray & Rao Yendluri) og Microsoft (Kyle G) på et standardiseret dynamisk SQL -koncept. Meget af systemet var baseret på Sybases DB-Library-system, hvor de Sybase-specifikke sektioner blev fjernet og flere tilføjelser til understøttelse af andre platforme. DB-Library blev hjulpet af et branchedækkende skifte fra bibliotekssystemer, der var tæt knyttet til et specifikt sprog, til bibliotekssystemer, der blev leveret af operativsystemet og krævede, at sprogene på platformen overholdt dets standarder. Dette betød, at et enkelt bibliotek kunne bruges med (potentielt) ethvert programmeringssprog på en given platform.

Det første udkast til Microsoft Data Access API blev offentliggjort i april 1989, omtrent samtidig med Lotus 'meddelelse om Blueprint. På trods af Blueprints store forspring - det kørte, da MSDA stadig var et papirprojekt - sluttede Lotus sig til sidst til MSDA -indsatsen, da det blev klart, at SQL ville blive de facto databasestandard. Efter betydelige input fra branchen blev standarden i sommeren 1989 til SQL Connectivity ( SQLC ).

SAG og CLI

I 1988 dannede flere leverandører, hovedsagelig fra Unix- og databasesamfundene, SQL Access Group (SAG) i et forsøg på at producere en enkelt grundlæggende standard for SQL -sproget. På det første møde var der betydelig debat om, hvorvidt indsatsen udelukkende skulle fungere på selve SQL-sproget eller forsøge en bredere standardisering, der også omfattede et dynamisk SQL-sprogindlejringssystem, det de kaldte et Call Level Interface (CLI) . Mens han deltog i mødet med et tidligt udkast til det, der dengang stadig var kendt som MS Data Access, inviterede Kyle Geiger fra Microsoft Jeff Balboni og Larry Barnes fra Digital Equipment Corporation (DEC) til også at deltage i SQLC -møderne. SQLC var en potentiel løsning på opfordringen til CLI, som blev ledet af DEC.

Den nye SQLC "bande på fire", MS, Tandem, DEC og Sybase bragte en opdateret version af SQLC til det næste SAG -møde i juni 1990. SAG reagerede ved at åbne standardindsatsen for ethvert konkurrerende design, men af ​​de mange forslag , kun Oracle Corp havde et system, der præsenterede alvorlig konkurrence. I sidste ende vandt SQLC stemmerne og blev udkast til standard, men først efter at store dele af API'en blev fjernet - standarddokumentet blev beskåret fra 120 sider til 50 i løbet af denne tid. Det var også i denne periode, at navnet Call Level Interface formelt blev vedtaget. I 1995 blev SQL/CLI en del af den internationale SQL-standard, ISO/IEC 9075-3. Den SAG selv blev overtaget af X / Open gruppe i 1996, og med tiden blev en del af The Open Group 's fælles Application Environment .

MS fortsatte arbejdet med den originale SQLC -standard og beholdt mange af de avancerede funktioner, der blev fjernet fra CLI -versionen. Disse inkluderede funktioner som f.eks. Markører , der kan rulles , og forespørgsler om metadata . Kommandoerne i API blev opdelt i grupper; Core -gruppen var identisk med CLI, niveau 1 -udvidelserne var kommandoer, der ville være lette at implementere i drivere, mens niveau 2 -kommandoer indeholdt de mere avancerede funktioner som markører. En foreslået standard blev frigivet i december 1991, og industriens input blev samlet og arbejdet ind i systemet gennem 1992, hvilket resulterede i endnu et navneændring til ODBC .

JET og ODBC

I løbet af denne tid var Microsoft i gang med at udvikle deres Jet -databasesystem. Jet kombinerede tre primære delsystemer; en ISAM- baseret databasemotor (også kaldet Jet , forvirrende), en C-baseret grænseflade, der giver applikationer adgang til disse data, og et udvalg af driver- dynamiske linkbiblioteker (DLL), der tillod den samme C-grænseflade at omdirigere input og output til andre ISAM-baserede databaser, som Paradox og xBase . Jet tillod at bruge et sæt opkald til at få adgang til fælles mikrocomputerdatabaser på en måde, der ligner Blueprint, og derefter omdøbt til DataLens. Jet brugte imidlertid ikke SQL; ligesom DataLens var grænsefladen i C og bestod af datastrukturer og funktionsopkald.

SAG -standardiseringsindsatsen gav Microsoft en mulighed for at tilpasse deres Jet -system til den nye CLI -standard. Dette ville ikke kun gøre Windows til en førende platform for CLI -udvikling, men også give brugerne mulighed for at bruge SQL til at få adgang til både Jet og andre databaser. Det, der manglede, var SQL-parseren, der kunne konvertere disse opkald fra deres tekstform til den C-grænseflade, der blev brugt i Jet. For at løse dette indgik MS et samarbejde med PageAhead Software om at bruge deres eksisterende forespørgselsprocessor, SIMBA. SIMBA blev brugt som en parser over Jets C -bibliotek, hvilket gjorde Jet til en SQL -database. Og fordi Jet kunne videresende disse C-baserede opkald til andre databaser, tillod dette også SIMBA at forespørge andre systemer. Microsoft inkluderede drivere til Excel til at omdanne sine regnearksdokumenter til SQL-tilgængelige databasetabeller.

Frigivelse og fortsat udvikling

ODBC 1.0 blev udgivet i september 1992. Dengang var der lidt direkte understøttelse af SQL -databaser (kontra ISAM), og tidlige drivere blev noteret for dårlig ydeevne. Noget af dette var uundgåeligt på grund af den vej, opkaldene tog gennem den Jet-baserede stak; ODBC-opkald til SQL-databaser blev først konverteret fra Simba Technologies SQL-dialekt til Jets interne C-baserede format og derefter videregivet til en driver til konvertering tilbage til SQL-opkald til databasen. Digital udstyr og Oracle indgav begge Simba Technologies til også at udvikle drivere til deres databaser.

Omkring 1993 sendte OpenLink Software en af ​​de første uafhængigt udviklede tredjeparts ODBC-drivere til PROGRESS DBMS og fulgte snart med deres UDBC (en cross-platform API-ækvivalent med ODBC og SAG/CLI) SDK og tilhørende drivere til PROGRESS , Sybase, Oracle og andre DBMS, til brug på Unix-lignende OS ( AIX , HP-UX , Solaris , Linux osv.), VMS , Windows NT , OS/2 og andet OS.

I mellemtiden trak CLI -standardindsatsen ud, og det var først i marts 1995, at den endelige version blev færdiggjort. På det tidspunkt havde Microsoft allerede givet Visigenic Software en kildekode- licens til at udvikle ODBC på ikke-Windows-platforme. Visigenic portede ODBC til Mac OS og en lang række Unix -platforme, hvor ODBC hurtigt blev de facto -standarden. "Ægte" CLI er sjælden i dag. De to systemer forbliver ens, og mange applikationer kan overføres fra ODBC til CLI med få eller ingen ændringer.

Over tid overtog databaseleverandørerne drivergrænsefladerne og leverede direkte links til deres produkter. At springe de mellemliggende konverteringer over til og fra Jet eller lignende indpakninger resulterede ofte i højere ydelse. På det tidspunkt havde Microsoft imidlertid ændret fokus til deres OLE DB -koncept (for nylig genindført), hvilket gav direkte adgang til en bredere vifte af datakilder fra adressebøger til tekstfiler. Flere nye systemer fulgte, hvilket yderligere henledte deres opmærksomhed fra ODBC, herunder ActiveX Data Objects (ADO) og ADO.net , som interagerede mere eller mindre med ODBC i løbet af deres levetid.

Da Microsoft vendte sin opmærksomhed væk fra at arbejde direkte på ODBC, omfavnede Unix -feltet det i stigende grad. Dette blev drevet frem af to ændringer på markedet, introduktionen af grafiske brugergrænseflader (GUI'er) som GNOME, der gav et behov for at få adgang til disse kilder i ikke-tekstform, og fremkomsten af åbne softwaredatabasesystemer som PostgreSQL og MySQL , i første omgang under Unix. Den senere vedtagelse af ODBC af Apple til brug af standard Unix-side iODBC- pakken Mac OS X 10.2 (Jaguar) (som OpenLink Software uafhængigt havde leveret til Mac OS X 10.0 og endda Mac OS 9 siden 2001) cementerede yderligere ODBC som standarden til dataadgang på tværs af platforme.

Sun Microsystems brugte ODBC -systemet som grundlag for deres egen åbne standard, Java Database Connectivity (JDBC). I de fleste måder, kan JDBC betragtes som en version af ODBC til programmeringssproget Java i stedet for C . JDBC-til-ODBC- broer giver Java-baserede programmer adgang til datakilder via ODBC-drivere på platforme, der mangler en indbygget JDBC-driver, selvom disse nu er relativt sjældne. Omvendt giver ODBC-til-JDBC-broer C-baserede programmer adgang til datakilder via JDBC-drivere på platforme eller fra databaser, der mangler passende ODBC-drivere.

ODBC i dag

ODBC er stadig i stor brug i dag, med drivere tilgængelige til de fleste platforme og de fleste databaser. Det er ikke ualmindeligt at finde ODBC-drivere til databasemotorer, der er beregnet til at blive integreret, som SQLite , som en måde at give eksisterende værktøjer mulighed for at fungere som front-ender til disse motorer til test og fejlfinding.

Stigningen af tynd klient computing ved hjælp af HTML som et mellemformat har reduceret behovet for ODBC. Mange webudviklingsplatforme indeholder direkte links til måldatabaser - MySQL er meget almindelig. I disse scenarier er der ingen direkte adgang på klientsiden eller flere klientsoftwaresystemer at understøtte; alt går gennem den programmeringsleverede HTML-applikation. Den virtualisering, som ODBC tilbyder, er ikke længere et stærkt krav, og udviklingen af ​​ODBC er ikke længere så aktiv som den engang var. Men selvom ODBC ikke længere er et stærkt krav til programmering af klient-server, er det nu vigtigere for adgang, virtualisering og integration i analytiske og datavidenskabelige scenarier. Disse nye krav afspejles i nye ODBC 4.0-funktioner såsom semi-strukturerede og hierarkiske data, webgodkendelse og forbedring af ydeevnen.

Versionshistorik

Versionshistorik:

  • 1.0: udgivet i september 1992
  • 2,0: c. 1994
  • 2.5
  • 3,0: c. 1995, John Goodson fra Intersolv og Frank Pellow og Paul Cotton fra IBM leverede betydelige input til ODBC 3.0
  • 3.5: c. 1997
  • 3,8: c. 2009, med Windows 7
  • 4.0: Udvikling annonceret juni 2016 med første implementering med SQL Server 2017 udgivet september 2017 og yderligere desktop -drivere sidst i 2018 sidste specifikation på Github

Chauffører og ledere

Chauffører

ODBC er baseret på enhedsdrivermodellen , hvor driveren indkapsler den logik, der er nødvendig for at konvertere et standardsæt med kommandoer og funktioner til de specifikke opkald, der kræves af det underliggende system. For eksempel præsenterer en printerdriver et standardsæt med udskrivningskommandoer, API, til applikationer, der bruger udskrivningssystemet. Opkald til disse API'er konverteres af driveren til det format, der bruges af den faktiske hardware, f.eks. PostScript eller PCL .

I tilfælde af ODBC indkapsler driverne mange funktioner, der kan opdeles i flere brede kategorier. Et sæt funktioner handler primært om at finde, oprette forbindelse til og afbryde fra det DBMS, som chaufføren taler med. Et andet sæt bruges til at sende SQL -kommandoer fra ODBC -systemet til DBMS, konvertere eller fortolke kommandoer, der ikke understøttes internt. For eksempel kan et DBMS, der ikke understøtter markører, efterligne denne funktionalitet i driveren. Endelig bruges et andet sæt kommandoer, mest brugt internt, til at konvertere data fra DBMS's interne formater til et sæt standardiserede ODBC -formater, der er baseret på C -sprogformaterne.

En ODBC-driver gør det muligt for et ODBC-kompatibelt program at bruge en datakilde , normalt et DBMS. Nogle ikke-DBMS-drivere findes, for sådanne datakilder som CSV- filer, ved at implementere et lille DBMS inde i selve driveren. ODBC -drivere findes for de fleste DBMS'er, herunder Oracle , PostgreSQL , MySQL , Microsoft SQL Server (men ikke for Compact aka CE -udgaven ), Sybase ASE , SAP HANA og DB2 . Fordi forskellige teknologier har forskellige muligheder, implementerer de fleste ODBC -drivere ikke al funktionalitet, der er defineret i ODBC -standarden. Nogle drivere tilbyder ekstra funktionalitet, der ikke er defineret af standarden.

Driver Manager

Enhedsdrivere regnes normalt, opsættes og administreres af et separat Manager -lag, hvilket kan give yderligere funktionalitet. For eksempel inkluderer udskrivningssystemer ofte funktionalitet til at levere spoolfunktionalitet oven på driverne, hvilket giver printspooling til enhver understøttet printer.

I ODBC leverer Driver Manager (DM) disse funktioner. DM kan opregne de installerede drivere og præsentere dette som en liste, ofte i en GUI-baseret form.

Men vigtigere for driften af ​​ODBC -systemet er DM's koncept for et datakildens navn (DSN). DSN'er indsamler yderligere oplysninger, der er nødvendige for at oprette forbindelse til en bestemt datakilde, i forhold til selve DBMS. For eksempel kan den samme MySQL- driver bruges til at oprette forbindelse til en hvilken som helst MySQL-server, men forbindelsesoplysningerne for at oprette forbindelse til en lokal privat server er forskellige fra de oplysninger, der er nødvendige for at oprette forbindelse til en internethostet offentlig server. DSN gemmer disse oplysninger i et standardiseret format, og DM giver dette til driveren under forbindelsesanmodninger. DM indeholder også funktionalitet til at præsentere en liste over DSN'er, der bruger menneskelige læsbare navne, og til at vælge dem ved løbetid for at oprette forbindelse til forskellige ressourcer.

DM indeholder også muligheden for at gemme delvist komplette DSN'er med kode og logik til at bede brugeren om eventuelle manglende oplysninger ved runtime. For eksempel kan et DSN oprettes uden et påkrævet kodeord. Når et ODBC -program forsøger at oprette forbindelse til DBMS'en ved hjælp af dette DSN, standser systemet og beder brugeren om at angive adgangskoden, før han fortsætter. Dette frigør applikationsudvikleren fra at skulle oprette denne slags kode, samt at skulle vide, hvilke spørgsmål der skal stilles. Alt dette er inkluderet i driveren og DSN'erne.

Brokonfigurationer

En bro er en særlig slags driver: en driver, der bruger en anden driverbaseret teknologi.

ODBC-til-JDBC (ODBC-JDBC) broer

En ODBC-JDBC-bro består af en ODBC- driver, der bruger tjenesterne fra en JDBC-driver til at oprette forbindelse til en database. Denne driver oversætter ODBC-funktionsopkald til JDBC-metodeopkald. Programmerere bruger normalt en sådan bro, når de mangler en ODBC -driver til en database, men har adgang til en JDBC -driver. Eksempler: OpenLink ODBC-JDBC Bridge , SequeLink ODBC-JDBC Bridge .

JDBC-til-ODBC (JDBC-ODBC) broer

En JDBC-ODBC-bro består af en JDBC-driver, der anvender en ODBC-driver til at oprette forbindelse til en måldatabase. Denne driver oversætter JDBC metode opkald til ODBC funktionskald. Programmerere bruger normalt en sådan bro, når en given database mangler en JDBC -driver, men er tilgængelig via en ODBC -driver. Sun Microsystems inkluderede en sådan bro i JVM , men betragtede den som en stop-gap-foranstaltning, mens få JDBC-drivere eksisterede (Den indbyggede JDBC-ODBC-bro blev droppet fra JVM i Java 8). Sun har aldrig tiltænkt sin bro til produktionsmiljøer, og anbefalede generelt mod brugen. Fra 2008 leverer uafhængige leverandører af dataadgang JDBC-ODBC-broer, der understøtter nuværende standarder for begge mekanismer, og som langt bedre end JVM's indbyggede. Eksempler: OpenLink JDBC-ODBC Bridge , SequeLink JDBC-ODBC Bridge .

OLE DB-til-ODBC broer

En OLE DB-ODBC-bro består af en OLE DB- udbyder, der bruger tjenesterne fra en ODBC-driver til at oprette forbindelse til en måldatabase. Denne provider oversætter OLE DB metode opkald til ODBC funktionskald. Programmerere bruger normalt en sådan bro, når en given database mangler en OLE DB -udbyder, men er tilgængelig via en ODBC -driver. Microsoft sender en, MSDASQL.DLL, som en del af MDAC- systemkomponentpakken sammen med andre databasedrivere for at forenkle udviklingen i COM-bevidste sprog (f.eks. Visual Basic ). Tredjeparter har også udviklet sådanne, især OpenLink-software, hvis 64-bit OLE DB-udbyder til ODBC-datakilder fyldte hullet, da Microsoft oprindeligt afskrev denne bro til deres 64-bit OS. (Microsoft gentog senere, og 64-bit Windows, der starter med Windows Server 2008 og Windows Vista SP1, er leveret med en 64-bit version af MSDASQL.) Eksempler: OpenLink OLEDB-ODBC Bridge , SequeLink OLEDB-ODBC Bridge .

ADO.NET-til-ODBC-broer

En ADO.NET-ODBC-bro består af en ADO.NET-udbyder, der bruger tjenesterne fra en ODBC-driver til at oprette forbindelse til en måldatabase. Denne provider oversætter ADO.NET metode opkald til ODBC funktionskald. Programmerere bruger normalt en sådan bro, når en given database mangler en ADO.NET -udbyder, men er tilgængelig via en ODBC -driver. Microsoft sender en som en del af bundtet MDAC -systemkomponenter sammen med andre databasedrivere for at forenkle udviklingen i C# . Tredjeparter har også udviklet sådanne. Eksempler: OpenLink ADO.NET-ODBC Bridge , SequeLink ADO.NET-ODBC Bridge .

Se også

Referencer

Bibliografi
  • Geiger, Kyle (1995). Inde i ODBC . Microsoft Press. ISBN 9781556158155.
Citater

eksterne links