Verbindungsdaten von ODBC für OLE DB-Verbindung nutzen?
Johannes Cramer
Hi allerseits,
Kann man es schaffen, eine ODBC-Verbindung so in einen Client einzubauen,
dass ich die Daten nicht in Klartext einsehen kann? Wenn nicht, dann k�nnte
ich doch die ODBC-Verbindung von Access zum SQL-Server auslesen durch
"?Currentdb.tabledef("verbundenetbl").connect". In der Registry kann ich
dann noch den Servernamen und alle anderen Infos unter HKEY_local_Machine
bzw. HKey_Current_User /Software/ODBC/ODBC.ini auslesen.
Also m��te ich dann alle Infos (Servername, User, Passwort - alles im
Klartext) zusammen haben, um mich auf diesen SQL-Server mit einer OLE-DB
Verbindung zu connecten? Richtig?
Oder kann der SQL-Server erkennen, ob ich mit ODBC oder OLE DB auf ihn
connecte und er blockt dann bei OLE DB ab, l��t aber ODBC zu? Benutzt ODBC
andere Ports oder sonstige andere Einstellungen, die mir eine Verbindung von
OLE DB statt ODBC zunicht machen kann?
Soweit ich das verstanden habe, ist ODBC der Golf und OLE DB der Mercedes.
Aber meiner Zieladresse, z.B. mein Wohnort (=Servername des SQL-Servers) und
der Username&Passwort der Garage (=Username&Passwort der SQL-Server) ist
gleich, ob ich mit dem Golf oder dem Mercedes dort hin fahre?
Wieder mal ein Dankesch�n f�r die Beantwortung meiner Fragen :-)
Viele Gr��e
Johannes
Christa Kurschat
"Johannes Cramer" <J.Cr...@gmx.net> schrieb im Newsbeitrag
news:eV9c210$JHA....@TK2MSFTNGP02.phx.gbl...
> Hi allerseits,
>
> Kann man es schaffen, eine ODBC-Verbindung so in einen Client einzubauen,
> dass ich die Daten nicht in Klartext einsehen kann? Wenn nicht, dann
> k�nnte
> ich doch die ODBC-Verbindung von Access zum SQL-Server auslesen durch
> "?Currentdb.tabledef("verbundenetbl").connect". In der Registry kann ich
> dann noch den Servernamen und alle anderen Infos unter HKEY_local_Machine
> bzw. HKey_Current_User /Software/ODBC/ODBC.ini auslesen.
>
> Also m��te ich dann alle Infos (Servername, User, Passwort - alles im
> Klartext) zusammen haben, um mich auf diesen SQL-Server mit einer OLE-DB
> Verbindung zu connecten? Richtig?
Soweit schon.
Aber der ODBC-Connectstring funktioniert nicht mit OleDB. Der sieht anders
aus.
Beispiel ODBC:
ODBC;DRIVER={SQL
Server};SERVER=Server\sql2005;DATABASE=MyDB;Trusted_Connection=Yes
Beispiel OleDB:
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security
Info=False;Initial Catalog=MyDB;Data Source=Server\sql2005;
Gru�
Christa
--
Access-FAQ: http://www.donkarl.com
SQL-Server-FAQ: www.sqlfaq.de
InsideSql: www.insidesql.org
Elmar Boye
Hallo Johannes,
Johannes Cramer schrieb:
> Kann man es schaffen, eine ODBC-Verbindung so in einen Client einzubauen,
> dass ich die Daten nicht in Klartext einsehen kann? Wenn nicht, dann kï¿œnnte
> ich doch die ODBC-Verbindung von Access zum SQL-Server auslesen durch
> "?Currentdb.tabledef("verbundenetbl").connect".
Das gilt nur fï¿œr Access/Jet.
Dort ist eine Verschlï¿œsselung der Verbindungsdaten nicht vorgesehen.
Und schon die Access Dokumentation rï¿œt ab, Kennwï¿œrter in Verbindungszeichenfolgen
zu speichern, und tut dies nur, wenn dies explizit eingestellt wurde.
Vielmehr wird vom Access beim ersten Zugriff Benutzer und Kennwort
abgefragt (erkennbar an dem spartanischen Dialog).
Diese Informationen wird zur Laufzeit zwischengespeichert und fï¿œr
die gleiche Verbindung weiterverwendet.
> In der Registry kann ich
> dann noch den Servernamen und alle anderen Infos unter HKEY_local_Machine
> bzw. HKey_Current_User /Software/ODBC/ODBC.ini auslesen.
In den ODBC.INI Eintrï¿œgen stehen keine Kennwï¿œrter.
Den Benutzer und das Kennwort, das Du im ODBC Verwaltungsdialog angibst,
gelten nur dort um zusï¿œtzliche Informationen vom Server fï¿œr den Dialog
(wie Sprache, Standarddatenbank) abzurufen.
Und das Kennwort wird dort nicht gespeichert.
Fￜr den Verbindungsaufbau einer Anwendung muￜ jeweils Benutzer
und Kennwort angegeben werden bzw. mit Schlï¿œsselwï¿œrtern (UID/PWD)
mitgegeben werden.
Anders ist die Option in Datei DSNs, dort kann das Kennwort (optional)
gespeichert werden (was man aber vermeiden sollte, eben weil es potentiell
unsicher ist).
> Also mￜￜte ich dann alle Infos (Servername, User, Passwort - alles im
> Klartext) zusammen haben, um mich auf diesen SQL-Server mit einer OLE-DB
> Verbindung zu connecten?
OleDb ist in der Hinsicht nicht anders und auch nicht (un)sicherer.
Fï¿œr in Access eingebundene Tabellen ist es zudem keine Option.
> Oder kann der SQL-Server erkennen, ob ich mit ODBC oder OLE DB auf ihn
> connecte und er blockt dann bei OLE DB ab, lￜￜt aber ODBC zu?
Den SQL Server interessiert das nicht wirklich.
> Soweit ich das verstanden habe, ist ODBC der Golf und OLE DB der Mercedes.
Das stimmt so nicht. Beides sind nur Schnittstellentechniken,
zu denen sich auch noch der .NET SqlClient gesellt, die fï¿œr die
ï¿œbertragung zum Client verwendet werden.
Auf Seiten des SQL Servers kommt immer das gleiche native
Protokoll (TDS) zum Einsatz. Und die Schnittstelle vermittelt
die darï¿œber gelieferten Daten zum Programm.
Das ODBC/OLEDB angeht sind die Gemeinsamkeiten sogar so groￜ,
dass der SQL Server Native Client die gleichen Programmdateien nutzt.
Und so hï¿œngt es am Ende viel mehr davon ab, was das Programm kann
(gelegentlich auch bevorzugt).
Access kennt wiederum fï¿œr eingebundene Tabellen nur ODBC -
schlicht und einfach weil die Funktion seit Anfang der 90er
Jahre existiert und damals nur ODBC existierte.
Und ODBC ist dort keinesfalls schlechter als OLEDB.
Gruￜ Elmar
Lutz Uhlmann
news:eV9c210$JHA....@TK2MSFTNGP02.phx.gbl...
>
> Kann man es schaffen, eine ODBC-Verbindung so in einen Client einzubauen,
> dass ich die Daten nicht in Klartext einsehen kann? Wenn nicht, dann k�nnte
> ich doch die ODBC-Verbindung von Access zum SQL-Server auslesen durch
> "?Currentdb.tabledef("verbundenetbl").connect". In der Registry kann ich
> dann noch den Servernamen und alle anderen Infos unter HKEY_local_Machine
> bzw. HKey_Current_User /Software/ODBC/ODBC.ini auslesen.
>
> Also m��te ich dann alle Infos (Servername, User, Passwort - alles im
> Klartext) zusammen haben, um mich auf diesen SQL-Server mit einer OLE-DB
> Verbindung zu connecten? Richtig?
> Oder kann der SQL-Server erkennen, ob ich mit ODBC oder OLE DB auf ihn
> connecte und er blockt dann bei OLE DB ab, l��t aber ODBC zu? Benutzt ODBC
> andere Ports oder sonstige andere Einstellungen, die mir eine Verbindung von
> OLE DB statt ODBC zunicht machen kann?
Wenn du keinen System-DSN benutzt stehen eigentlich auch keine Verbindungsdaten in der Registry.
Du mu�t den ConnectionString f�r deine Verbindung in der Anwendung zusammenstellen und dann die
Verbindung aufbauen.
Du bist mit dieser Frage aber wohl besser in der NG microsoft.public.de.access.clientserver
aufgehoben.
Ein Beispiel von Josef P�tzl findest du unter
http://access.joposol.com/downloads/anwendungen/dbms-test.html
Lutz
Johannes Cramer
danke f�r die Auskunft, aber ich will die Infos aus der ODBC-Verbindung
gebrauchen, um im SSIS eine OLE-DB Verbindung zu dem Server aufzubauen. Wir
wollen die Access Auswertung auf einen 2. SQL-Server portieren :-)
Viele Gr��e
Johannes
Johannes Cramer
Danke Lutz,
w�re fast besser gewesen, aber dachte die SQL Leute sind fitter :-)
J
Johannes Cramer
Hi Elmar,
von Dir kommen mal wieder die ausf�hrlichen, intersanten Infos - ohne die
anderen Antworten abzumildern :-)
DANKE!
>> Kann man es schaffen, eine ODBC-Verbindung so in einen Client einzubauen,
>> dass ich die Daten nicht in Klartext einsehen kann? Wenn nicht, dann
>> k�nnte
>> ich doch die ODBC-Verbindung von Access zum SQL-Server auslesen durch
>> "?Currentdb.tabledef("verbundenetbl").connect".
>
> Das gilt nur f�r Access/Jet.
> Dort ist eine Verschl�sselung der Verbindungsdaten nicht vorgesehen.
>
Es gibt also Frontends, die eine ODBC-Verbindung so verschl�sseln k�nnen,
dass man sie nicht einsehen kann? Welche g�be es da zum Beispiel?
>> In der Registry kann ich
>> dann noch den Servernamen und alle anderen Infos unter HKEY_local_Machine
>> bzw. HKey_Current_User /Software/ODBC/ODBC.ini auslesen.
>
> In den ODBC.INI Eintr�gen stehen keine Kennw�rter.
Danke f�r die Info. In ein paar Internetforen und auch in manchen B�chern
steht, dass man in der Registry die Zeichenfolge "Passwort" hinzuf�gen kann,
aber ich habe das nie hinbekommen ...
>> Oder kann der SQL-Server erkennen, ob ich mit ODBC oder OLE DB auf ihn
>> connecte und er blockt dann bei OLE DB ab, l��t aber ODBC zu?
>
> Den SQL Server interessiert das nicht wirklich.
DANKE! Das war wichtig f�r's Verst�ndnis.
>> Soweit ich das verstanden habe, ist ODBC der Golf und OLE DB der
>> Mercedes.
>
> Das stimmt so nicht. Beides sind nur Schnittstellentechniken,
> zu denen sich auch noch der .NET SqlClient gesellt, die f�r die
> �bertragung zum Client verwendet werden.
> Auf Seiten des SQL Servers kommt immer das gleiche native
> Protokoll (TDS) zum Einsatz. Und die Schnittstelle vermittelt
> die dar�ber gelieferten Daten zum Programm.
Ganz verstehe ich das noch nicht. Was ist der Unterschied zwischen einer
Schnittstelle und einem Protokoll?
Spiegelt die Grafik
Client | Schnittstelle Protokoll | Server
-----------------------------------------------------------------------------
| |
----ODBC \ |
Access | > TDS --------- SQL Server
----OLE DB / |
| |
>
> Das ODBC/OLEDB angeht sind die Gemeinsamkeiten sogar so gro�,
> dass der SQL Server Native Client die gleichen Programmdateien nutzt.
> Und ODBC ist dort keinesfalls schlechter als OLEDB.
Aber alle schreien doch immer, dass ODBC viel langsamer w�re als OLE DB -
ohne das meist n�her zu begr�nden. Ist also der Geschwindigkeitsunterschied
nicht gegeben. Wenn ja, warum schreien denn dann immer alle so?
Danke f�r das Licht im Dunklen, was hoffentlich immer Heller wird :-)
Viele Gr��e
Johannes
Elmar Boye
Hallo Johannes,
Johannes Cramer schrieb:
>>> Kann man es schaffen, eine ODBC-Verbindung so in einen Client einzubauen,
>>> dass ich die Daten nicht in Klartext einsehen kann? Wenn nicht, dann
>>> kï¿œnnte
>>> ich doch die ODBC-Verbindung von Access zum SQL-Server auslesen durch
>>> "?Currentdb.tabledef("verbundenetbl").connect".
>> Das gilt nur fï¿œr Access/Jet.
>> Dort ist eine Verschlï¿œsselung der Verbindungsdaten nicht vorgesehen.
>>
> Es gibt also Frontends, die eine ODBC-Verbindung so verschlï¿œsseln kï¿œnnen,
> dass man sie nicht einsehen kann?
Zunï¿œchst: Ich habe von den Verbindungsinformationen gesprochen!
Die lassen sich weder bei OleDb noch bei ODBC von Haus aus verschlï¿œsseln,
da die Treiber eine Zeichenfolge benï¿œtigen.
Die spï¿œtere Datenï¿œbertragung zwischen Client und SQL Server kannst Du
via SSL verschlï¿œsseln, das wï¿œre aber eine andere Baustelle.
>>> In der Registry kann ich
>>> dann noch den Servernamen und alle anderen Infos unter HKEY_local_Machine
>>> bzw. HKey_Current_User /Software/ODBC/ODBC.ini auslesen.
>> In den ODBC.INI Eintrï¿œgen stehen keine Kennwï¿œrter.
> Danke fï¿œr die Info. In ein paar Internetforen und auch in manchen Bï¿œchern
> steht, dass man in der Registry die Zeichenfolge "Passwort" hinzufï¿œgen kann,
> aber ich habe das nie hinbekommen ...
Man kann schon, nur der Treiber tut das von Haus aus nicht.
Das Schlï¿œsselwort wï¿œre "PWD" und in Verbindung UID (Benutzer),
ebenso wie in der Verbindungszeichenfolge.
Nur muￜ man das manuell eintragen - und sollte es aus
Sicherheitsgrï¿œnden gar nicht erst tun.
>>> Soweit ich das verstanden habe, ist ODBC der Golf und OLE DB der
>>> Mercedes.
>> Das stimmt so nicht. Beides sind nur Schnittstellentechniken,
> Ganz verstehe ich das noch nicht. Was ist der Unterschied zwischen einer
> Schnittstelle und einem Protokoll?
Deine folgende Ascii-Grafik stellt das schon ganz gut dar!
> Spiegelt die Grafik
>
> Client | Schnittstelle Protokoll | Server
> -----------------------------------------------------------------------------
> | |
> ----ODBC \ |
> Access | > TDS --------- SQL Server
> ----OLE DB / |
> | |
>> Und ODBC ist dort keinesfalls schlechter als OLEDB.
> Aber alle schreien doch immer, dass ODBC viel langsamer wï¿œre als OLE DB -
> ohne das meist nï¿œher zu begrï¿œnden. Ist also der Geschwindigkeitsunterschied
> nicht gegeben. Wenn ja, warum schreien denn dann immer alle so?
Die Unterschiede, die dort vielfach gemessen werden, rï¿œhren zu groï¿œen Teilen
von der Anbindung der Programme an die Datenschnittstellem (ODBC, OLEDB)
selbst her. Und weniger an der Schnittstelle an sich.
Und wie gut die Anbindung ist, stark davon ab, wieviel Aufwand dort
betrieben wurde.
Und so gilt bei Access, dass die ODBC Unterstï¿œtzung bereits bei Access 1.1
(Anfang der 90er) in die JET Engine eingebaut wurde und in der Folgezeit
verbessert und erweitert, so z. B. RDO (ODBCDirect).
OleDb hat man mit Access 2000 nachgerï¿œstet, weil OleDb damals als "state of the art"
galt. Vor allem weil vieles (wie z. B. VBA) auf COM als Basistechnologie basiert.
In der Anfangszeit war das noch ziemlich wackelig - mittlerweile ist
die Technik auch dort weitgehend ausgereift.
Nur hat sich bei Microsoft der Wind in Richtung .NET Technologie gedreht,
und OleDb ist in den Hintergrund gerï¿œckt.
Access hat diesen Schritt bisher nicht mitgemacht und man hat anstatt
dessen wieder ODBC (und DAO) aus der Mottenkiste geholt.
(und z. B. ADP in die Versenkung verschwinden lassen, die von OleDb
wesentlich mehr profitierten).
Nur ist da viel (Produkt)politik im Spiel, die ich hier nicht
weiter kommentieren will.
Soweit es den SQL Server betrifft werden alle Schnittstellen
(ODBC, OleDb, .NET) auf die gleiche Art und Weise bedient.
Die messbaren Unterschiede, wenn man die Anbindung der Programme
weitgehend ausschlieￜt, kommen von dem Aufwand der betrieben werden muￜ,
eine Anweisung in T-SQL umzuwandeln und via TDS zu transportieren.
Da die Rechner aber immer schneller geworden sind, ist der Aufwand
dort heute weitgehend zu vernachlï¿œssigen.
Konzentrieren sollte man sich deswegen auf die Art und Weise, wie
man die Daten abruft. Denn da kann man sehr viel mehr verkehrt machen.
Gruￜ Elmar
Christa Kurschat
Hallo Johannes,
"Johannes Cramer" <J.Cr...@gmx.net> schrieb im Newsbeitrag
news:uLYRWb$$JHA....@TK2MSFTNGP03.phx.gbl...
W�re gut gewesen, wenn Du das gleich im Originalpost so beschrieben h�ttest.
Was Du f�r dsen SSIS brauchst, ist Server, Datenbank, Benutzer und Passwort.
Im SSIS�re da sdann auch verschl�sselt, nur bekommst Du es weder aus der
ODBC- noch aus der OleDB-Verbindung heraus, wie Elmar ja schon schrieb.
Im SSIS w�rde ich das aber komplett neu machen und per Konfuguration
hinterlegen.
Gru�
Christa
Johannes Cramer
> Zun�chst: Ich habe von den Verbindungsinformationen gesprochen!
> Die lassen sich weder bei OleDb noch bei ODBC von Haus aus verschl�sseln,
> da die Treiber eine Zeichenfolge ben�tigen.
> Die sp�tere Daten�bertragung zwischen Client und SQL Server kannst Du
> via SSL verschl�sseln, das w�re aber eine andere Baustelle.
Ich darf Deine Worte wieder per Grafiken verdeutlichen?
Im Client Transportebene
Im Server
|------------------------|
|-----------------------|
| Hier keine
|Verbindungsinfos & |
| Verschl�sselung | TDS (ODBC/OLEDB) |Daten NICHT
|
| von Verbindungsinfos --------------------------------->
|unverschl�sselbar |
| ODBC oder OLEDB | Daten / Verbindungsinfos | (je nach
Benutzer- |
| m�glich! | per SSL verschl�sselbar |
rechten einsehbar) |
|------------------------|
|------------------------|
>>> Und ODBC ist dort keinesfalls schlechter als OLEDB.
>> Aber alle schreien doch immer, dass ODBC viel langsamer w�re als OLE DB.
> Die Unterschiede, die dort vielfach gemessen werden, r�hren zu gro�en
> Teilen
> von der Anbindung der Programme an die Datenschnittstellem (ODBC, OLEDB)
> selbst her. Und weniger an der Schnittstelle an sich.
Wieder eine Grafik?
Im Client
Im Server
------------------------------------------------------------------------------------
|---------------|
|------------------------------|
| (1) | |
(3) |
| /---ODBC------TDS -----ODBC-- Passt Access-SQL-Syntax |
|Access < | | mit
SQL-Server-Syntax |
| \ --OLE DB-----TDS-----OE DB-- �berein
|
| (3) (2) | |
(SQL-Server) |
|---------------|
|------------------------------|
Also geht es hier um zwei Punkte:
Anbindung der Schnittstellen durch die Microsoft-Programmierer: Punkt (1)
und (2)
Programmierung des Entwicklers: Punkt (3)
Punkt: (1) und (2)
Die Programmierer von Mircosoft, welche f�r die Anbindung von ODBC (1) und
OLE DB (2) innerhalb des Clients z.B. Access zust�ndig sind. Hier kann man
bei Access 2002, 2003 und 2007 sagen, dass beide Treiber gleich gut
eingebunden sind und deshalb hier keine Geschwindigkeitsunterscheide zu
verzeichnen sind, vielleicht auf einem 486er, 512KB Ram, aber nicht mehr auf
einem Dualcore, 2GB? Richtig? ... Gilt diese Aussage (Geschwindigkeit ODBC =
OLE DB) auch, wenn man bei ODBC das "ODBC direct" (=Weiterentwicklung von
ODBC) NICHT dazuz�hlt, also eine System-DSN als ODBC-Schnittstellt nimmt?
Oder haben die Access-Programmierer die Schnittstellen-Programmierung von
ODBC auf dem Stand von Access 1.1. gelassen und OLE BD im Jahre 2000 deshalb
einfach besser eingebunden? O.k, das ist jetzt eine Access-Frage, aber
vielleicht kannst Du sie mir auch beantworten?
Punkt (3)
Dein Worte:
> Die messbaren Unterschiede, wenn man die Anbindung der Programme
> weitgehend ausschlie�t, kommen von dem Aufwand der betrieben werden mu�,
> eine Anweisung in T-SQL umzuwandeln und via TDS zu transportieren.
> Konzentrieren sollte man sich deswegen auf die Art und Weise, wie
> man die Daten abruft. Denn da kann man sehr viel mehr verkehrt machen.
Der Anwendungsprogrammierer, welcher bei Punkt (3) aufpassen muss, dass die
Access-SQL-Syntax mit der SQL-Server-Syntax kompatibel ist, da sonst unn�tig
Daten hin und her transportiert werden m�ssen. "SELECT * FROM Kunden WHERE
InStr(1,Name,'Sch')<>0" wird nicht von SQL-Server verstanden, weil SQL
Server die Access-Funktion "InStr" nicht kennt. vgl.
http://msdn.microsoft.com/de-de/library/bb979206.aspx. ABER: Punkt (3)
(=Passt Access-SQL-Syntax mit SQL-Server-Syntax �berein?) kann mir sowohl
bei OLE DB als auch bei ODBC passieren? Richtig?
Server SSIS-Paket Client
--------------------------------------------------------------------------------------
|----------------|
|-----------------|
| | |
(5) |
| ---ODBC------TDS -----ODBC |
| SQL Server | | Oracle
|
| (4) ---ODBC------TDS ---- ODBC |
| | |
|
|----------------|
|------------------|
Punkt (4) und (5)
Dein Worte:
> Soweit es den SQL Server betrifft werden alle Schnittstellen
> (ODBC, OleDb, .NET) auf die gleiche Art und Weise bedient.
Aus Geschwindigkeitsgesichtspunkten ist es also wurscht, wenn ich mir in SQL
Server aus Oracle Daten per SSIS ziehen m�chte, ob ich als Quelle die
ODBC-Schnittstelle oder die OLE DB-Schnittstelle nehme - unter der Annahme,
dass auch in Oracle beide Schnittstellen gleich schnell / gut angebunden
/programmiert sind?
Viele Gr��e und Danke f�r's Anz�nden der Kerzen in dieser dunklen ODBC/OLE
DB-Welt :-)
Johannes
"Elmar Boye" <Elm...@gmx.net> schrieb im Newsbeitrag
news:%23KQRl1G...@TK2MSFTNGP05.phx.gbl...
>
> Hallo Johannes,
>
> Johannes Cramer schrieb:
>>>> Kann man es schaffen, eine ODBC-Verbindung so in einen Client
>>>> einzubauen,
>>>> dass ich die Daten nicht in Klartext einsehen kann? Wenn nicht, dann
>>>> k�nnte
>>>> ich doch die ODBC-Verbindung von Access zum SQL-Server auslesen durch
>>>> "?Currentdb.tabledef("verbundenetbl").connect".
>>> Das gilt nur f�r Access/Jet.
>>> Dort ist eine Verschl�sselung der Verbindungsdaten nicht vorgesehen.
>>>
>> Es gibt also Frontends, die eine ODBC-Verbindung so verschl�sseln k�nnen,
>> dass man sie nicht einsehen kann?
>
> Zun�chst: Ich habe von den Verbindungsinformationen gesprochen!
> Die lassen sich weder bei OleDb noch bei ODBC von Haus aus verschl�sseln,
> da die Treiber eine Zeichenfolge ben�tigen.
>
> Die sp�tere Daten�bertragung zwischen Client und SQL Server kannst Du
> via SSL verschl�sseln, das w�re aber eine andere Baustelle.
>
>>>> In der Registry kann ich
>>>> dann noch den Servernamen und alle anderen Infos unter
>>>> HKEY_local_Machine
>>>> bzw. HKey_Current_User /Software/ODBC/ODBC.ini auslesen.
>>> In den ODBC.INI Eintr�gen stehen keine Kennw�rter.
>> Danke f�r die Info. In ein paar Internetforen und auch in manchen B�chern
>> steht, dass man in der Registry die Zeichenfolge "Passwort" hinzuf�gen
>> kann,
>> aber ich habe das nie hinbekommen ...
>
> Man kann schon, nur der Treiber tut das von Haus aus nicht.
> Das Schl�sselwort w�re "PWD" und in Verbindung UID (Benutzer),
> ebenso wie in der Verbindungszeichenfolge.
>
> Nur mu� man das manuell eintragen - und sollte es aus
> Sicherheitsgr�nden gar nicht erst tun.
>
>>>> Soweit ich das verstanden habe, ist ODBC der Golf und OLE DB der
>>>> Mercedes.
>>> Das stimmt so nicht. Beides sind nur Schnittstellentechniken,
>
>> Ganz verstehe ich das noch nicht. Was ist der Unterschied zwischen einer
>> Schnittstelle und einem Protokoll?
>
> Deine folgende Ascii-Grafik stellt das schon ganz gut dar!
>
>> Spiegelt die Grafik
>>
>> Client | Schnittstelle Protokoll |
>> Server
>> -----------------------------------------------------------------------------
>> |
>> |
>> ----ODBC \ |
>> Access | > TDS --------- SQL
>> Server
>> ----OLE DB / |
>> |
>> |
>
>>> Und ODBC ist dort keinesfalls schlechter als OLEDB.
>> Aber alle schreien doch immer, dass ODBC viel langsamer w�re als OLE DB -
>> ohne das meist n�her zu begr�nden. Ist also der
>> Geschwindigkeitsunterschied
>> nicht gegeben. Wenn ja, warum schreien denn dann immer alle so?
>
> Die Unterschiede, die dort vielfach gemessen werden, r�hren zu gro�en
> Teilen
> von der Anbindung der Programme an die Datenschnittstellem (ODBC, OLEDB)
> selbst her. Und weniger an der Schnittstelle an sich.
>
> Und wie gut die Anbindung ist, stark davon ab, wieviel Aufwand dort
> betrieben wurde.
>
> Und so gilt bei Access, dass die ODBC Unterst�tzung bereits bei Access 1.1
> (Anfang der 90er) in die JET Engine eingebaut wurde und in der Folgezeit
> verbessert und erweitert, so z. B. RDO (ODBCDirect).
>
> OleDb hat man mit Access 2000 nachger�stet, weil OleDb damals als "state
> of the art"
> galt. Vor allem weil vieles (wie z. B. VBA) auf COM als Basistechnologie
> basiert.
> In der Anfangszeit war das noch ziemlich wackelig - mittlerweile ist
> die Technik auch dort weitgehend ausgereift.
>
> Nur hat sich bei Microsoft der Wind in Richtung .NET Technologie gedreht,
> und OleDb ist in den Hintergrund ger�ckt.
> Access hat diesen Schritt bisher nicht mitgemacht und man hat anstatt
> dessen wieder ODBC (und DAO) aus der Mottenkiste geholt.
> (und z. B. ADP in die Versenkung verschwinden lassen, die von OleDb
> wesentlich mehr profitierten).
>
> Nur ist da viel (Produkt)politik im Spiel, die ich hier nicht
> weiter kommentieren will.
>
> Soweit es den SQL Server betrifft werden alle Schnittstellen
> (ODBC, OleDb, .NET) auf die gleiche Art und Weise bedient.
>
> Die messbaren Unterschiede, wenn man die Anbindung der Programme
> weitgehend ausschlie�t, kommen von dem Aufwand der betrieben werden mu�,
> eine Anweisung in T-SQL umzuwandeln und via TDS zu transportieren.
>
> Da die Rechner aber immer schneller geworden sind, ist der Aufwand
> dort heute weitgehend zu vernachl�ssigen.
>
> Konzentrieren sollte man sich deswegen auf die Art und Weise, wie
> man die Daten abruft. Denn da kann man sehr viel mehr verkehrt machen.
>
> Gru� Elmar
>
>
>
Johannes Cramer
Noch mal der Post, weil die Grafiken diesmal nicht geklappt haben. Habe den
Post auch inhaltlich noch etwas verbessert. Ich hoffe, Du hast Dich nicht zu
sehr im alten vergraben.
> Zun�chst: Ich habe von den Verbindungsinformationen gesprochen!
> Die lassen sich weder bei OleDb noch bei ODBC von Haus aus verschl�sseln,
> da die Treiber eine Zeichenfolge ben�tigen.
> Die sp�tere Daten�bertragung zwischen Client und SQL Server kannst Du
> via SSL verschl�sseln, das w�re aber eine andere Baustelle.
Ich darf Deine Worte wieder per Grafiken verdeutlichen?
Im Client Transportebene Im SQL Server
----------------------------------------------------------
|------| |--------|
| | (b) | |
| (a) -----------------------> (a) |
| | | |
|------| |--------|
Legende:
(a) Weder im Client noch im Server ist eine Verschl�sselung
vonVerbindungsinfos bei ODBC oder OLE DB m�glich.
(b) Daten / Verbindungsinfos (per SSL) sind verschl�sselbar!
>>> Und ODBC ist dort keinesfalls schlechter als OLEDB.
>> Aber alle schreien doch immer, dass ODBC viel langsamer w�re als OLE DB.
> Die Unterschiede, die dort vielfach gemessen werden, r�hren zu gro�en
> Teilen
> von der Anbindung der Programme an die Datenschnittstellem (ODBC, OLEDB)
> selbst her. Und weniger an der Schnittstelle an sich.
Wieder eine Grafik?
Im Client Im Server
------------------------------------------------------------------
|---------------| |-------------|
| (2) | (1) |
| /---ODBC-----TDS ----ODBC-
| (3) < | | (3)
| \ --OLE DB-----TDS---OE DB--
| (2) | (1) |
|---------------| |--------------|
Legende:
(1) Die Treiber an sich unterscheiden sich nicht in der Geschwindigkeit,
weil sie beide das TDS-Protokoll nutzen.
Geschwindigekitsprobleme treten eher in 2 Punkten auf:
(2) Microsoft-Programmierer: Anbindung der Schnittstellen
(3) Anwenderprogrammierer: Passt Access-SQL-Syntax mit SQL-Server-Syntax
�berein?
zu (2)
Die Programmierer von Mircosoft, welche f�r die Anbindung von ODBC und OLE
DB innerhalb des Clients z.B. Access zust�ndig sind, k�nnten beide Treiber
gleich gut eingebinden. Das ist in der Praxis bei Access nicht geschehen,
aber die Geschwindigkeitsunterschiede sind vielleicht nur auf einem
Uralt-Rechner, aber nicht mehr auf den heutigen Rechner zu messen.
Gilt diese Aussage (Geschwindigkeit ODBC = OLE DB) auch, wenn man bei ODBC
das "ODBC direct" (=Weiterentwicklung von ODBC) NICHT dazuz�hlt, also eine
System-DSN als ODBC-Schnittstellt nimmt?
zu (3)
> Die messbaren Unterschiede, wenn man die Anbindung der Programme
> weitgehend ausschlie�t, kommen von dem Aufwand der betrieben werden mu�,
> eine Anweisung in T-SQL umzuwandeln und via TDS zu transportieren.
> Konzentrieren sollte man sich deswegen auf die Art und Weise, wie
> man die Daten abruft. Denn da kann man sehr viel mehr verkehrt machen.
Der Anwendungsprogrammierer muss beachten, dass die Access-SQL-Syntax mit
der SQL-Server-Syntax kompatibel ist, da sonst unn�tig
Daten hin und her transportiert werden m�ssen. "SELECT * FROM Kunden WHERE
InStr(1,Name,'Sch')<>0" wird nicht von SQL-Server verstanden, weil SQL
Server die Access-Funktion "InStr" nicht kennt. vgl.
http://msdn.microsoft.com/de-de/library/bb979206.aspx.
ABER: Punkt (3) (=Passt Access-SQL-Syntax mit SQL-Server-Syntax �berein?)
kann mir sowohl bei OLE DB als auch bei ODBC passieren? Richtig?
Weiteres Beispiel SQL Server <--> Oracle
Server SSIS-Paket Client
----------------------------------------------------------------
|----------------| |-----------------|
| | | (5)
| -- ODBC----TDS ---ODBC
| SQL Server | | Oracle
| --OLE DB---TDS --- OLE BD
| (4) | � |
|----------------| |-----------------|
Punkt (4) und (5)
> Soweit es den SQL Server betrifft werden alle Schnittstellen
> (ODBC, OleDb, .NET) auf die gleiche Art und Weise bedient.
Wenn ich mir in SQL Server aus Oracle Daten per SSIS ziehen m�chte, ist es
aus Geschwindigkeitsgesichtspunkten gleich, ob ich als Quelle die
Elmar Boye
Hallo Johannes,
Johannes Cramer schrieb:
> Noch mal der Post, weil die Grafiken diesmal nicht geklappt haben.
Newsgroup mit eignen sich dafï¿œr nur bedingt.
> Habe den Post auch inhaltlich noch etwas verbessert.
> Ich hoffe, Du hast Dich nicht zu sehr im alten vergraben.
Nein, zwischen Deinen beiden Beitrï¿œgen habe ich (endlich wieder mal) geschlafen ;-))
>> Zunï¿œchst: Ich habe von den Verbindungsinformationen gesprochen!
>> Die lassen sich weder bei OleDb noch bei ODBC von Haus aus verschlï¿œsseln,
>> da die Treiber eine Zeichenfolge benï¿œtigen.
>> Die spï¿œtere Datenï¿œbertragung zwischen Client und SQL Server kannst Du
>> via SSL verschlï¿œsseln, das wï¿œre aber eine andere Baustelle.
>
> Ich darf Deine Worte wieder per Grafiken verdeutlichen?
Hier fï¿œllt die Grafik etwas zu knapp aus.
> Im Client Transportebene Im SQL Server
> ----------------------------------------------------------
> |------| |--------|
> | | (b) | |
> | (a) -----------------------> (a) |
> | | | |
> |------| |--------|
>
> Legende:
> (a) Weder im Client noch im Server ist eine Verschlï¿œsselung
> vonVerbindungsinfos bei ODBC oder OLE DB mï¿œglich.
Verschlï¿œsselbar in ihrer Gesamtheit: Nein, Sicherbar: Ja!
Denn zum einen ist bei Windows Authentifizierung das Kennwort
sicher im Active Directory verwahrt.
Die bevorzugte Nutzung von Windows Authentifizierung wird
empfohlen, wann immer mï¿œglich.
Was SQL Authentifizierung angeht: Der SQL Server verschlï¿œsselt
Kennwï¿œrter in einem nicht reversiblen Verfahren (Hash).
Auf Client Seite ist eine direkte Verschlï¿œsselung nicht
vorgesehen und die Anwendung muￜ dort selbst tￜtig werden.
Das bereits hï¿œufiger angesprochene Access sieht dort nichts
vor (auch eine Alterserscheinung).
Eigene Anwendungen kï¿œnnen ï¿œber das Windows Crypto API
ebenso ihre Informationen verschlï¿œsseln. Wobei sie
sie allerdings beim Verbindungsaufbau wieder entschlï¿œsseln
mï¿œssen (und die Daten liegen lesbar zumindest im Speicher vor).
> (b) Daten / Verbindungsinfos (per SSL) sind verschlï¿œsselbar!
Einiges mehr auch von der konzeptionellen Seite findest Du
http://blogs.msdn.com/lcris/archive/2006/11/30/who-needs-encryption.aspx
(und dort finden sich einige mehr.
Wie dort durchscheint: Nur verschlï¿œsseln alleine bringt wenig,
das eigentliche Wichtige ist die Daten zu vor fremden
Zugriff zu sichern.
>>>> Und ODBC ist dort keinesfalls schlechter als OLEDB.
>>> Aber alle schreien doch immer, dass ODBC viel langsamer wï¿œre als OLE DB.
>> Die Unterschiede, die dort vielfach gemessen werden, rï¿œhren zu groï¿œen
>> Teilen von der Anbindung der Programme an die Datenschnittstellem (ODBC, OLEDB)
>> selbst her. Und weniger an der Schnittstelle an sich.
> Wieder eine Grafik?
Die stￜￜt an die Grenzen der Mￜglichkeiten von Zeichengrafiken.
> Im Client Im Server
> ------------------------------------------------------------------
> |---------------| |-------------|
> | (2) | (1) |
> | /---ODBC-----TDS ----ODBC-
> | (3) < | | (3)
> | \ --OLE DB-----TDS---OE DB--
> | (2) | (1) |
> |---------------| |--------------|
>
> Legende:
> (1) Die Treiber an sich unterscheiden sich nicht in der Geschwindigkeit,
> weil sie beide das TDS-Protokoll nutzen.
> Geschwindigekitsprobleme treten eher in 2 Punkten auf:
> (2) Microsoft-Programmierer: Anbindung der Schnittstellen
> (3) Anwenderprogrammierer: Passt Access-SQL-Syntax mit SQL-Server-Syntax
> ï¿œberein?
>
> zu (2)
> Die Programmierer von Mircosoft, welche fï¿œr die Anbindung von ODBC und OLE
> DB innerhalb des Clients z.B. Access zustï¿œndig sind, kï¿œnnten beide Treiber
> gleich gut eingebinden. Das ist in der Praxis bei Access nicht geschehen,
> aber die Geschwindigkeitsunterschiede sind vielleicht nur auf einem
> Uralt-Rechner, aber nicht mehr auf den heutigen Rechner zu messen.
> Gilt diese Aussage (Geschwindigkeit ODBC = OLE DB) auch, wenn man bei ODBC
> das "ODBC direct" (=Weiterentwicklung von ODBC) NICHT dazuzï¿œhlt, also eine
> System-DSN als ODBC-Schnittstellt nimmt?
>
> zu (3)
>> Die messbaren Unterschiede, wenn man die Anbindung der Programme
>> weitgehend ausschlieￜt, kommen von dem Aufwand der betrieben werden muￜ,
>> eine Anweisung in T-SQL umzuwandeln und via TDS zu transportieren.
>> Konzentrieren sollte man sich deswegen auf die Art und Weise, wie
>> man die Daten abruft. Denn da kann man sehr viel mehr verkehrt machen.
>
> Der Anwendungsprogrammierer muss beachten, dass die Access-SQL-Syntax mit
> der SQL-Server-Syntax kompatibel ist, da sonst unnï¿œtig
> Daten hin und her transportiert werden mï¿œssen. "SELECT * FROM Kunden WHERE
> InStr(1,Name,'Sch')<>0" wird nicht von SQL-Server verstanden, weil SQL
> Server die Access-Funktion "InStr" nicht kennt. vgl.
> http://msdn.microsoft.com/de-de/library/bb979206.aspx.
Dem Artikel sieht man sein Alter an - er wurde noch fï¿œr Access 97
erstellt und mit der Jet 4.0 (Access 2000++) hat sich dort noch
einiges zum besseren geï¿œndert.
> ABER: Punkt (3) (=Passt Access-SQL-Syntax mit SQL-Server-Syntax ï¿œberein?)
> kann mir sowohl bei OLE DB als auch bei ODBC passieren? Richtig?
Richtig.
Vor kommen aber auch einige Dinge hinzu:
Kennt der Entwickler, die fï¿œr ihn relevanten Konstrukte in SQL.
(Relevant insofern als man fï¿œr die meisten Anwendungen nicht
der SQL Guru sein muￜ).
Kennt er die Mechanismen, mit denen die Anbindung geschieht.
Das gilt fï¿œr Access, aber auch bei allen anderen Anwendungen,
wie die heute in .NET mit O/R Mappern usw. erstellt werden.
Denn je abstrakter die Anbindung ist, umso mehr hï¿œngt es
davon ab, dass die Abfragen konform damit erfolgen.
Denn aus meiner Erfahrung (mittlerweile fast 9 Jahre) sowohl
in Access wie SQL Server und .NET Gruppen rï¿œhren die Mehrzahl
der Probleme eher daher als aus Problemen mit den Schnittstellen
(auch wenn die mal gerne als Bï¿œsewichte hergenommen werden
oder auch der SQL Server selbst).
>> Soweit es den SQL Server betrifft werden alle Schnittstellen
>> (ODBC, OleDb, .NET) auf die gleiche Art und Weise bedient.
> Wenn ich mir in SQL Server aus Oracle Daten per SSIS ziehen mï¿œchte, ist es
> aus Geschwindigkeitsgesichtspunkten gleich, ob ich als Quelle die
> ODBC-Schnittstelle oder die OLE DB-Schnittstelle nehme - unter der Annahme,
> dass auch in Oracle beide Schnittstellen gleich schnell / gut angebunden
> /programmiert sind?
Das gilt (leider) nicht - und deswegen das ursprï¿œngliche "soweit es...".
Denn neben Microsoft (die haben es erfunden!) hat kaum ein Hersteller
eine so vollstï¿œndige und _stabile_ OleDb Anbindung erstellt -
was zu groï¿œen Teilen an der Komplexitï¿œt von OleDb liegt.
Auch wenn Oracle als einer der wenigen nahe dran kommt,
so gab es da immer mehr Probleme.)
Und auch dazu gefï¿œhrt hat, das OleDb mit .NET krï¿œftig an Bedeutung
verloren hat. Denn dort hat man die Schnittstellen krï¿œftig entschlackt.
Und so ist das erstellen eines stabilen und schnellen .NET Treibers
um einiges einfacher.
Mittlerweile kann man von wohl von allen Herstellern sagen, dass sie
stabile .NET Treiber anbieten. Und wo immer mï¿œglich sollte man diese
verwenden.
SSIS wiederum ist ein Zwitter. Denn auch wenn er ï¿œber eine .NET Schnittstelle
programmiert wird, so ist vieles noch auf der Basis von COM erstellt worden
(weil als Nachfolger von DTS bereits vor dem Aufkeimen von .NET begonnen).
Was die Schnittstellen angeht, befolgt er aber die Tugenden von .NET:
Datenzugriff mit einfachsten Mitteln (u. a. keine Cursor oder andere Spielchen,
die wiederum viel vom Treiber verlangen). Und so ist dort die Schnittstellenwahl
wesentlich sekundï¿œrer.
Wenn sollte man dort den stabilsten Treiber und an zweiter Stelle
mit dem schnellsten Zugriff wï¿œhlen.
(Bei Oracle dï¿œrfte das sowohl fï¿œr .NET als auch ODBC gelten.)
Nur kommt das oben gesagte bei SSIS deutlich zum Tragen:
Man muￜ die Mechanismen verstehen, wie SSIS arbeitet.
Denn SSIS ist wesentlich mehr als nur das Schieben von einer Datenquelle
zur anderen. Wer sich darauf beschrï¿œnkt, ist jemand der einen
Formel-I Wagen wie einen VW Golf auf der Straï¿œe fï¿œhrt
=> kann man machen, sï¿œuft aber unheimlich viel Sprit,
ohne das man schneller ans Ziel kommt ;-).
Die wichtigeren Komponenten von SSIS sind vielmehr die Transformationen,
mit deren geschickter Anwendung viel mehr an Leistung herausgeholt werden
kann - vor allem im Zeitalter von Multi-Core CPUs.
Aber das fï¿œhrt alles sehr weit vom Ausgangsthema ab,
deswegen will ich es gut sein lassen.
Gruￜ Elmar
Johannes Cramer
es wird immer aller verst�ndlicher. Danke. ich darf deshalb mal
zusammenfassen, um die komplexe Materie irgendwie auf einen Nenner zu
bekommen?
Zusammenfassung f�r Sichtbarkeit von User und Passwort, nachdem ich mich in
ein paar andere Foren rumgrtrieben habe - wo sich leider widerspr�chliche
Angaben finden: Deshalb:
Gleich mit welchem Programm (Access, SQL-Server, Oracle, etc.) ich mich auf
anderen Computer (Access, SQL-Server, Oracle, etc. ) verbinde, ich kann im
Speicher bei einer ODBC, OLE DB und .Net -Verbindung User und Passwort
auslesen, weil - egal wie ich innerhalb des Programms oder auf dem
Transportwege verschl�ssele - , die Schnittstellen immer User und Passwort
im Klartext braucht. Richtig?
Ausnahme: Ich nehme bei ODBC oder OLE DB oder .Net die "Trusted_Connection",
dann steht kein User und Passwort im Speicher - was aber nur zwischen
Microsoft-Produkten geht. Richtig?
Beispiel:
ODBC: ODBC;DRIVER={SQL
Server};SERVER=Server\sql2005;DATABASE=MyDB;Trusted_Connection=Yes Beispiel
OleDB:
OLE DB: Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security
Info=False;Initial Catalog=MyDB;Data Source=Server\sql2005;
Hier finden sich keine User und Passw�rter im Speicher, weil interne
Sicherheit von Microsoft.
Steht zwar ein bi�chen in Widerspruch zu unserer Korrespondenz, deshalb die
Frage: Richtig?
By the way: Danke f�r den Link mit dem Verschl�sseln. Hat einem das ein oder
andere bewu�ter gemacht.
Zusammenfassung f�r Geschwindigkeit:
Bei SQL-Server und Oracle sind ODBC, OLE DB und .Net aus
Geschwindigkeitsgesichtspunkten etwa gleich angebunden. Richtig?
Bei Access sind ODBC und OLE DB auch in etwa gleich eingebunden
(Geschwindigkeitsunterschiede auf modernen Rechner nicht messbar), nur .net
fehlt. Richtig?
Diese Aussagen gelten ohne ODBC Direct. Richtig?
Bei anderen Anbietern kann man schlecht Aussagen treffen, man muss es
messen:
Ich jage 5 Mio Datens�tze (Select * from tbl_riesig) von einem zum anderen
Rechner einmal �ber ODBC und dann �ber OLE DB und dann �ber .Net und messe
die Zeit. Wenn alle anderen Faktoren, Netzwerklast, Netzwerkgeschwindigkeit
und das Wetter :-) gleich sind, dann kann man sehen, wie gut die beiden
Schnittstellen angebunden sind.
Geschwindigkeitsprobleme sind meist dem Anwenderentwickler in die Schuhe zu
schieben :-)
>> Der Anwendungsprogrammierer muss beachten, dass die Access-SQL-Syntax mit
>> der SQL-Server-Syntax kompatibel ist, da sonst unn�tig
>> Daten hin und her transportiert werden m�ssen. "SELECT * FROM Kunden
>> WHERE
>> InStr(1,Name,'Sch')<>0" wird nicht von SQL-Server verstanden, weil SQL
>> Server die Access-Funktion "InStr" nicht kennt. vgl.
>> http://msdn.microsoft.com/de-de/library/bb979206.aspx.
> Dem Artikel sieht man sein Alter an - er wurde noch f�r Access 97
> erstellt und mit der Jet 4.0 (Access 2000++) hat sich dort noch
> einiges zum besseren ge�ndert.
Damit mir das nicht passiert, suche ich B�cher, Webseiten, weitere MSDN
Infos ... ich finde da leider nichts ... und das ist ja eigentlich das
wichtigste beim Programmieren? Kannst Du mir da irgendwelche Tipps geben?
Viele Gr��e und herzlichen Dank f�r die ganzen Infos. Es wird langsam Licht
:-)
Johannes
Elmar Boye
"Johannes Cramer" <J.Cr...@gmx.net> schrieb ...
> es wird immer aller verst�ndlicher. Danke. ich darf deshalb mal
> zusammenfassen, um die komplexe Materie irgendwie auf einen Nenner zu
> bekommen?
Das wird ja ein Dauerbrenner...
> Zusammenfassung f�r Sichtbarkeit von User und Passwort, nachdem ich mich in
> ein paar andere Foren rumgrtrieben habe - wo sich leider widerspr�chliche
> Angaben finden: Deshalb:
> Gleich mit welchem Programm (Access, SQL-Server, Oracle, etc.) ich mich auf
> anderen Computer (Access, SQL-Server, Oracle, etc. ) verbinde, ich kann im
> Speicher bei einer ODBC, OLE DB und .Net -Verbindung User und Passwort
> auslesen, weil - egal wie ich innerhalb des Programms oder auf dem
> Transportwege verschl�ssele - , die Schnittstellen immer User und Passwort
> im Klartext braucht.
> Richtig?
Der Transportweg (im Netzwerk) kann schon verschl�sselt sein,
also wie bereits erw�hnt SSL oder IPSec (VPN).
> Ausnahme: Ich nehme bei ODBC oder OLE DB oder .Net die "Trusted_Connection",
> dann steht kein User und Passwort im Speicher - was aber nur zwischen
> Microsoft-Produkten geht. Richtig?
Auch andere Produkte/Plattformen kennen sichere Authentifizierungsverfahren,
wie z. B. Kerberos (m. W. Oracle uam.) - das ist auch auf *NIX verf�gbar.
> Beispiel:
> ODBC: ODBC;DRIVER={SQL
> Server};SERVER=Server\sql2005;DATABASE=MyDB;Trusted_Connection=Yes Beispiel
> OleDB:
> OLE DB: Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security
> Info=False;Initial Catalog=MyDB;Data Source=Server\sql2005;
> Hier finden sich keine User und Passw�rter im Speicher, weil interne
> Sicherheit von Microsoft.
> Steht zwar ein bi�chen in Widerspruch zu unserer Korrespondenz,
ich sehe da keine Widerspr�che, Du siehst sie wo?
> Zusammenfassung f�r Geschwindigkeit:
> Bei SQL-Server und Oracle sind ODBC, OLE DB und .Net aus
> Geschwindigkeitsgesichtspunkten etwa gleich angebunden. Richtig?
Vorsicht! Ich habe mich nur auf SQL Server bezogen.
Oracle ist ein ganz anderes Thema.
So ist z. B. die Access / SQL Server ODBC Anbindung stellenweise besser,
da dort Optimierungen vorkommen, die bei anderen Produkten nicht
verwendet werden.
Und Oracle macht durch z. B. durch seine spezielle Behandlung
von Zahlen (NUMBER f�r alles) und auch Zeichenkettenbehandlung,
die Anbindung in der Microsoft Welt durchg�ngig etwas schwieriger.
> Bei Access sind ODBC und OLE DB auch in etwa gleich eingebunden
> (Geschwindigkeitsunterschiede auf modernen Rechner nicht messbar), nur .net
> fehlt. Richtig?
Nein. Auch wenn die OLEDB/ODBC Treiber noch ziemlich gleich darstehen,
mu� man f�r Access sagen, das dort beide Dinge getrennt sind, dort gilt
zun�chst: ODBC f�r eingebundene Tabellen, OLEDB f�r ADP.
Wenn man dann eine eingebundene Tabelle �ber OLEDB zugreift,
macht man einen Dreisprung ADO/OLEDB -> JET -> ODBC
(was niemals besser wird).
> Bei anderen Anbietern kann man schlecht Aussagen treffen, man muss es
> messen:
> Ich jage 5 Mio Datens�tze (Select * from tbl_riesig) von einem zum anderen
> Rechner einmal �ber ODBC und dann �ber OLE DB und dann �ber .Net und messe
> die Zeit.
Das w�re eine zu optimistische Messmweise.
Gestreamt (alle Zeilen und Spalten in der gelieferten Reihenfolge)
sind sicherlich die Daten von allen Treibern am schnellsten zu bew�ltigen.
Die G�te von Treibern mi�t sich aber eher wenn es Zugriffe ausser der
Reihe gibt. �blicherweise merkt man Probleme meist erst dann,
weil in solchen Szenarien Probleme wie schlechte Speicherverwaltung
(bis hin zu Speicherlecks) uvm. zum Tragen kommen...
> Wenn alle anderen Faktoren, Netzwerklast, Netzwerkgeschwindigkeit
> und das Wetter :-) gleich sind, dann kann man sehen, wie gut die beiden
> Schnittstellen angebunden sind.
... eben das Wetter (nicht nur in Deutschland) wechselhaft ;-))
> Geschwindigkeitsprobleme sind meist dem Anwenderentwickler in die Schuhe zu
> schieben :-)
wenn auch nicht meist, so doch h�ufiger als denen lieb ist ;-)
>>> http://msdn.microsoft.com/de-de/library/bb979206.aspx.
>> Dem Artikel sieht man sein Alter an - er wurde noch f�r Access 97
>> erstellt und mit der Jet 4.0 (Access 2000++) hat sich dort noch
>> einiges zum besseren ge�ndert.
> Damit mir das nicht passiert, suche ich B�cher, Webseiten, weitere MSDN
> Infos ... ich finde da leider nichts ... und das ist ja eigentlich das
> wichtigste beim Programmieren? Kannst Du mir da irgendwelche Tipps geben?
Was Access angeht ist lange nicht mehr wirklich Neues geschrieben worden.
Wie bereits gesagt, die ODBC Anbindung existiert seit Urtagen und
die letzten "Verbesserungen" betrafen Unicode und einiges mehr mit
der Jet 4.0 (aus dem Ende des letzten Jahrhunderts 1999/2000):
http://support.microsoft.com/kb/275561
Alte B�cher wie z. B. "Microsoft Access Developer's Guide to SQL Server"
(Baron, Chipman) sind insoweit immer noch anwendbar.
Auch die Dinge, die in der Access Client/Server Gruppe
http://groups.google.de/group/microsoft.public.de.access.clientserver
geschrieben wurden, gelten noch.
Bis etwa 2003 zu guten Teilen von mir, nur habe ich Access zugunsten
von .NET den R�cken gedreht, weil das Produkt _leider_ im Stillstand
verharrt - (optische) Kosmetik au�en vorgelassen.
Gru� Elmar
Johannes Cramer
Danke, wirklich Danke, f�r die umfassenden Erkl�rungen. Endlich glaube ich
es verstanden zu haben.
Aber Du hast noch einen interessanten Punkt angesprochen:
> > Bei anderen Anbietern kann man schlecht Aussagen treffen, man muss es
> > messen:
> > Ich jage 5 Mio Datens�tze (Select * from tbl_riesig) von einem zum
> > anderen
> > Rechner einmal �ber ODBC und dann �ber OLE DB und dann �ber .Net und
> > messe
> > die Zeit.
> Das w�re eine zu optimistische Messmweise.
> Gestreamt (alle Zeilen und Spalten in der gelieferten Reihenfolge)
> sind sicherlich die Daten von allen Treibern am schnellsten zu bew�ltigen.
> Die G�te von Treibern mi�t sich aber eher wenn es Zugriffe ausser der
> Reihe gibt. �blicherweise merkt man Probleme meist erst dann,
> weil in solchen Szenarien Probleme wie schlechte Speicherverwaltung
> (bis hin zu Speicherlecks) uvm. zum Tragen kommen...
Kann man das irgendwie blastisch erkl�ren? Er erfinde ein Beispiel: "ODBC
schreibt die Daten zuf�llig in den Speicher, und so kommt es zu Problemen.
Deshalb wurde bei OLE DB ge�ndert. OLEDB schreibt deshalb die Daten in
aufeinander folgende Speicherbl�cke."
Weil ich leider nicht wei�, wie es zu Speicherlecks kommen kann. Muss ich
mir unter Speicherlecks eine Art Festplattenfragmentiert - nur im RAM -
vorstellen?
Viele Gr��e
Johannes
Elmar Boye
Johannes Cramer schrieb:
> Aber Du hast noch einen interessanten Punkt angesprochen:
>
>>> Bei anderen Anbietern kann man schlecht Aussagen treffen,
>>> man muss es messen:
>>> Ich jage 5 Mio Datensï¿œtze (Select * from tbl_riesig) von einem zum
>>> anderen Rechner einmal ï¿œber ODBC und dann ï¿œber OLE DB und dann
>>> ï¿œber .Net und messe die Zeit.
>> Das wï¿œre eine zu optimistische Messmweise.
>> Gestreamt (alle Zeilen und Spalten in der gelieferten Reihenfolge)
>> sind sicherlich die Daten von allen Treibern am schnellsten zu bewï¿œltigen.
>> Die Gï¿œte von Treibern miï¿œt sich aber eher wenn es Zugriffe ausser der
>> Reihe gibt. ï¿œblicherweise merkt man Probleme meist erst dann,
>> weil in solchen Szenarien Probleme wie schlechte Speicherverwaltung
>> (bis hin zu Speicherlecks) uvm. zum Tragen kommen...
>
> Kann man das irgendwie blastisch erklï¿œren? Er erfinde ein Beispiel: "ODBC
> schreibt die Daten zufï¿œllig in den Speicher, und so kommt es zu Problemen.
> Deshalb wurde bei OLE DB geï¿œndert. OLEDB schreibt deshalb die Daten in
> aufeinander folgende Speicherblï¿œcke."
Das hï¿œngt nur indirekt mit der Schnittstelle zusammen.
Im Kern ist es eher ein Alltagsweisheit:
Programmierer machen Fehler und je mehr Code sie schreiben,
um so mehr davon...
und je umfangreicher (komplexer) Code wird, um so hï¿œufiger.
Und fï¿œr die drei erwï¿œhnten Schnittstellen gilt i. a., dass
der .NET Client der einfachste, der OleDB Client der komplexeste
in der Realisierung ist und ODBC liegt irgendwo dazwischen.
> Weil ich leider nicht weiￜ, wie es zu Speicherlecks kommen kann.
> Muss ich mir unter Speicherlecks eine Art Festplattenfragmentiert
> - nur im RAM - vorstellen?
Mehr verlorener Speicher.
Das ist solcher, den die Anwendung zwar fï¿œr sich reklamiert,
aber nicht mehr nutzt, dafï¿œr neuen vom Betriebssystem anfordert,
bis es keinen mehr gibt.
Mehr dazu <URL:http://de.wikipedia.org/wiki/Speicherleck>
Gruￜ Elmar
Johannes Cramer
verstanden! Auch hier wieder ein dickes Dankesch�n f�r Deine Worte.
Besonders klasse ist die Erkl�rung des Speicherlecks f�r Leute, die keine
Programmierkenntnisse haben :-) Danke f�r den Link.
Ich glaube, der Dauerbrenner ist beendet :-) Dir viel Erholung :-)
Viele Gr��e
Johannes
"Elmar Boye" <Elm...@gmx.net> schrieb im Newsbeitrag
news:7d398nF...@mid.individual.net...
Hallo Johannes,
Johannes Cramer schrieb:
> Aber Du hast noch einen interessanten Punkt angesprochen:
>
>>> Bei anderen Anbietern kann man schlecht Aussagen treffen,
>>> man muss es messen:
>>> Ich jage 5 Mio Datens�tze (Select * from tbl_riesig) von einem zum
>>> anderen Rechner einmal �ber ODBC und dann �ber OLE DB und dann
>>> �ber .Net und messe die Zeit.
>> Das w�re eine zu optimistische Messmweise.
>> Gestreamt (alle Zeilen und Spalten in der gelieferten Reihenfolge)
>> sind sicherlich die Daten von allen Treibern am schnellsten zu
>> bew�ltigen.
>> Die G�te von Treibern mi�t sich aber eher wenn es Zugriffe ausser der
>> Reihe gibt. �blicherweise merkt man Probleme meist erst dann,
>> weil in solchen Szenarien Probleme wie schlechte Speicherverwaltung
>> (bis hin zu Speicherlecks) uvm. zum Tragen kommen...
>
> Kann man das irgendwie blastisch erkl�ren? Er erfinde ein Beispiel: "ODBC
> schreibt die Daten zuf�llig in den Speicher, und so kommt es zu Problemen.
> Deshalb wurde bei OLE DB ge�ndert. OLEDB schreibt deshalb die Daten in
> aufeinander folgende Speicherbl�cke."
Das h�ngt nur indirekt mit der Schnittstelle zusammen.
Im Kern ist es eher ein Alltagsweisheit:
Programmierer machen Fehler und je mehr Code sie schreiben,
um so mehr davon...
und je umfangreicher (komplexer) Code wird, um so h�ufiger.
Und f�r die drei erw�hnten Schnittstellen gilt i. a., dass
der .NET Client der einfachste, der OleDB Client der komplexeste
in der Realisierung ist und ODBC liegt irgendwo dazwischen.
> Weil ich leider nicht wei�, wie es zu Speicherlecks kommen kann.
> Muss ich mir unter Speicherlecks eine Art Festplattenfragmentiert
> - nur im RAM - vorstellen?
Mehr verlorener Speicher.
Das ist solcher, den die Anwendung zwar f�r sich reklamiert,
aber nicht mehr nutzt, daf�r neuen vom Betriebssystem anfordert,
bis es keinen mehr gibt.
Mehr dazu <URL:http://de.wikipedia.org/wiki/Speicherleck>
Gru� Elmar