Unterschied ODBC und .NET

odbc ist eine Schnittstelle im Betriebsystem, da brauchst du also nur 
ein connector für odbc und kannst jeden Datenbank die ein odbc treiber 
hat ansprechen.

Aber das 64bit problem sollte es bei .net gar nicht geben, weil es erst 
zur laufzeit an die Hardware gebunden ist.
Jede .net dll die ich bis jetzt hatte lief auch unter 64bit.

Dass heißt es ist egal ob ich eine .NET connector oder einen ODBC 
connector verwende?

Mit dieser Frage möchte ich nur erfahren ob er ein Programm welches ich 
mit einer .NET dll verbunden habe auch bei meinem Kollegen funktioniert, 
welcher ein ODBC Connector installiert hat, oder ob man den Programmcode 
verändern muss.

Nein, funktioniert nicht. Du müsstest die Connector-DLL mitliefern. Oder 
eben Code anpassen.

Wie kann ich die Connector dll mitliefern?

Es sind 2 völlig verschiedene Sachen.

Wenn man über ODBC auf eine Datenbank zugrift, hat das den Vorteil, daß 
man die Datenbank auswechseln kann. ODBC ist ein 
Datenbankschnittstellenstandard. Zugegeben mit Unterschieden, jede 
Datenbank hat eine andere Leistungsfähigkeit oder Einschränkungen, aber 
grundsätzlich sind sie austauschbar. Du bist also nicht auf MySQL 
festgenagelt.

Datenbankconnectoren die explizit kein ODBC verwenden wenden sich direkt 
an die Datenbank, sie ist also nicht austauschbar. Schneller wird es 
dadurch kaum, aber der Hersteller hat dich in Monopolhaftung genommen. 
Daher wäre es saublöd, Schnittstellen ohne ODBC zu verwenden.


DoTNET ist nun eine Programmungeung von Microsoft ähnlich Java, die auf 
Pseudo-Code aufsetzt und C# und ein paar anderen einige 
Programmiersprachen anbietet, für diese Umgebung zu programmieren. Der 
Vorteil ist, daß es moderne Libraries gibt um auf verschiedendste Dinge 
zuuzgreifen und der alte Schrott wie MFC überwunden wurde. Darunter 
Libraries um auf Datenbanken zuzugreifen. Aber nur evenfalls in DotNET 
(in C# o.ä.) geschriebene Datenbanken können ohne Umwege verwendet 
werden. Die allermeisten Datenbanken sind aber nicht in DotNET nativ. 
Also wird sowieso über eine Schnittstelle auf die Datenbank zugegriffen. 
Dafür bietet sich ODBC an. Die Performanz ist durch den Sprung von 
DotNET zum nativen Betriebssystem sowieso behindert.

Du wirst aus einem DotNET Programm heraus also so oder so über einen 
DotNET Datenbankconnector auf eine Datenbank zugrifen. Aber möglichst 
über ODBC. Dann kannst du statt MySQL auch jede andere ansprechen.

Allerdings hat DotNET nicht den besten Ruf, es war ja als "Java-Killer" 
von Microsoft gedacht, und so hat das Marketing den Begriff inzwischen 
aufgeweicht. Eigentlich heisst inzwischen alles von Microsoft .NET, auch 
vieles welches überhaupt nicht auf der DotNET virtuelle Maschine 
aufsetzt.

Die Maschine an sich ist nicht schlecht, aber ähnlich wie JRE nervt 
viele Leute daß man sie "clumsy" ist. Ein natives Programm für Win32 
wird meist viel besseren Eindruck hinterlassen. Da gibt es übrigens auch 
ODBC. Nur keinen DotNET Connector.

OK, aber mein Problem ist nun ich habe das ganze Programm schon fertig 
und das mit einem .NET Connector, wie kann ich nun die dll mitschicken, 
wenn ich das Programm einem Kollegen geben möchte?

Frank Esselbach schrieb:
> db_select(sql):xml

klar es macht ja auch sinn nativ Datentypen intern in XML zu wandlen um 
sie dann wieder zurück zu wandeln. Und da wundern sich die leute warum 
die Computer so langsam sind.

Auch kann man mit Datenbanken ein ganzes stück mehr mache, was ist mit 
preapared statements? Bulktransfers, setzen von autocommit und noch 
einiges mehr. Es hat schon sein grund warum ODCB nicht nur aus 3 
Funktionen besteht.

Hallo,

Also ich kenn die Situation von Java, wo es genauso  möglich ist
JDBC (entspricht ado.net) und ODBC zu verwenden.

ODBC wird ausdrücklich nur als Notlösung angeboten fallse keine 
JDBC-Treiber
verfügbar sind.

ODBC einrichten kann je nach datenbank und os relativ aufwendig sein,
native ado.net dlls bzw. java .jars hingegen liefert man einfach mit der
Anwendung aus.

Exception Handling und Debugging ist weit einfacher und robuster mit 
nativem
.net code.

Das man mit ado.net nicht DB-unabhängig programmieren kann stimmt auch 
nicht,
es gibt Factorys für die Treiber und man kann (und sollte) auf die 
Interfaces anstatt direkt auf die Treiber programmieren:
http://msdn.microsoft.com/en-us/library/cy5kfe3c.aspx

Frank Esselbach schrieb:
> Bei einer "kleinen" Datenbankanwendung ist die Performance (bei den
> heutigen PCs) vollkommen unerheblich, da zählt (für den Entwickler)
> Universalität - und die von mir genannten Maßnahmen sind der Schlüssel
> dazu.

ich kennn leider Anwendungen die mit einer 500Mbyte Datenbank aktuelle 
PC lahmlegen. Und das liegt nur an der Art der Programmierung.

> Ja, kann man, damit verlässt man aber sofort den Pfad der
> DB-Unabhängigkeit. Versuch' mal einen Oracle-Trigger nach MySQL zu
> übertragen. Das muss man sicher, wenn man aus einer "Großen"
> Serverlösung das Maximum an Leistung und Sicherheit herausholen will.
> Für ein par Messwerte oder eine Bauteilbibliothek eher unbedeutend oder
> gar hinderlich ...

kann ich nicht nachvollziehen, habe erfolgreich zwischen Mysql, PostSql, 
SQL-Server und Oracel geswitcht (Windows und Linux).

ODBC ist zwar nicht schön, aber sehr ausgereift und jeder anständige DB 
hat ODBC.

> Die Antwortmenge eines SQL-Statements (der sog. "cursor") wird
> intern (m.E.) ohnehin als XML ausgeliefert.

Sachkunde kann eine lebhafte Diskussion nur behindern.

(ich weiss, der Spruch ist geklaut).


> Das man mit ado.net nicht DB-unabhängig programmieren kann
> stimmt auch nicht,

Kann man.
Die Frage ist, ob man unterschiedliche Datenbanken anschliessen kann.
Kann man auch, da ADO dazu nötigenfalls über ODBC geht.

ADO ist ein OLE Wrapper über Datenbanken, darunter ODBC ansprechbare 
Datenbanken.