webForumDet fria alternativet

Kan det vara så här, månne?

.NET

0 svar · 279 visningar · startad av ElMaco

Medlem sedan juni 2000161 inlägg
Frågan#1

Ok, jag börjar nysta i det själv, så får vi se hur långt vi kommer...

ODBC
Open Database Connectivity
Använder SQL för att fråga o manipulera data
Kan bara arbeta med relationsdatabaser
Har varit med länge och kan användas mot nästan alla relationsdatabaser som används idag.

ODBC har ett API med funktioner som ett program kan använda.

Funktionerna påverkar ODBC Drivers som hanterar de olika SQL-dialekterna som förekommer hos de olika databaserna. Man måste ha en driver för varje databastyp som skall accessas; MS SQL, Oracle, Sybase m.fl.

ODBC Driver Manager är ett bibliotek som binder samman applikationer med rätt ODBC-rutin. Denna hittas under Administrative Tools. (Där du sätter upp DSN:er vanligtvis.)

ODBC API:t är komplicerat.

ODBC är industristandard,emn man strävar efter ett migrera över till OLE DB. (?)

DAO
Data Access Objects
Huvudsakligen tänkt för PC-datorer som använder Microsoft Jet Data Engine Exempel på sådana anslutningar är MS Access, FoxPro o Dbase. Det extra Jet-lagret var långsammare än andra lösningar.

RDO
Remote Data Objects släpptes senare och designades för att arbeta mot ODBC. Genom att använda RDO kan man gå förbi Jet-lagret och ansluta direkt mot ODBC.

DAO-modell
DAO>Jet Engine>ODBC Driver Manager>ODBC Driver>DB

RDO-modell
RDO>ODBC Driver Manager>ODBC Driver>DB

Numer har vi även data som inte lagras enligt strikt relationsmodell. Vi behöver teknik att nå denna relationella data såväl som den ickerelationella. Därmed tillämpar vi ny teknik...

UDA
Universal Data Access
En strategi/arbetssätt för att kunna nå vilken typ av data/media som helst. Strategi; inte teknik som ODBC eller ADO.

UDA bygger på användandet av ADO. DAO och RDO kan inte omedelbart omsättas i UDA-strategi eftersom de måste skrivas om till ADO.

UDA med ADO ger oss möjligheten till disconnected recordsets. Vi kan ta ned data från DB, manipulera och skicka tillbaka. Bra för webbapplikationer.

ADO
ActiveX Data Objects

ODBC och ADO utgör tillsammans med RDS och OLE DB det som distribueras i MDAC, Microsoft Data Access Components.

High-Level interface för att nå data.

OLE DB
Object Linking and Embedding Database
UDA-strategins grundpelare.
OLE DB består av en trave COM komponenter för att ansluta till de olika datakällorna.

Low-level teknologi för att nå data.

OLE DB har egenskaper som är nyttiga, sk. Service Components:

Cursor Service för att söka o manipulera data i ett disconnected recordset.

Session Pooling för att administrera connections (?)

Transaction Enlistment (?)

Data Shape Provider (?)

Persistence Provider för att spara data till filer o skicka dem över nätverk.

Remote Data Provider göra tt du kan utnyttja en annan dator som erbjuder OLE DB i nätverket.

Så länge en datakälla uppfyller en viss objektmodell så kan den nås via OLE DB. (Antaligen ett kontrakt som tillämpas via alla COM-komponenterna. Och därmed kan man nå sånt som inte förefaller vara en relationsdatabas - typ ett e-postprogram, Internetpublicering, Active Directory)

Ok, det här var bara en bakgrund; nu så kommer the good stuff. Det är så här man har pysslat ihop det gamla ODBC-API:t med den nya UDA-filosofin med OLE DB:

ADO (ActixeX Data Objects) har ett förenklat API som styr OLE DB:ns olika nyttiga egenskaper, Service Components. (T.ex. Set oRs = Server.CreateObject("ADODB.Recordset") för att manipulera cursors.) OLE DB:n styr i sin tur ODBC:ns knepiga API och därigenom kan vi nå alla datakällor som har en ODBC-driver. Denna modellen heter MSDASQL och användes först 1996.

Klient>ADO>OLE DB Service Components>ODBC OLE DB Data Provider>ODBC Driver Manager>ODBC Driver>DB

Ok, då kan vi tolka en connectionsträng:

"PROVIDER=MSDASQL;DRIVER={Microsoft Access Driver (*.mdb) DBQ=C:\Test\Data.mdb}"

Om man vill kan man stryka två lager i modellen ovan genom att använda en annan OLE DB-provider; SQLOLEDB. Den gör så att ADO-metoderna styr OLE DB direkt mot Databasen istället för mot ODBC-hanteraren och deras olika ODBC-drivrutiner. Nu har vi alltså tagit bort ODBC som vi alltid annars betraktat som "standard".

Ok, detta är vad jag fick fram genom att bläddra i några böcker o läsa på nätet. Det kommer alltid en stackars okunnig efter mig som frågar samma sak - o ingen orkar skriva detta igen. Jag kan iofs inte garantera att allt som skrivits är riktigt - någon får gärna faktakolla.

Så, dags för lördagspilsner...

/M.

275 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
134 ms — deklarationer (db)
0 ms — hämta statistik (cache)
139 ms — hämta tråd, inlägg och bilagor (db)
133 ms — ändringar (db)