Forum: PC-Programmierung Unterschied ODBC und .NET


von mysql (Gast)


Lesenswert?

Hallo,

ich hätte eine kleine Fragen und zwar:
ein kollege von mir möchte auf eine mysql - Datenbank zugreifen, nun 
habe ich ihm gesagt, dass ich einen .net connector heruntergeladen habe.
Mein Kollege hat jedoch ein 64 bit System und er findet keinen .net 
connector für 64 bit.

Kann mir jemand von euch sagen ob es einen solchen Connector gibt und 
was der Unterschied von einem .Net Connector zu einem ODBC Connector 
ist.

mfG mysql

von Peter (Gast)


Lesenswert?

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.

von mysql (Gast)


Lesenswert?

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

von mysql (Gast)


Lesenswert?

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.

von G.a.s.t (Gast)


Lesenswert?

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

von mysql (Gast)


Lesenswert?

Wie kann ich die Connector dll mitliefern?

von MaWin (Gast)


Lesenswert?

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.

von mysql (Gast)


Lesenswert?

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?

von Arc N. (arc)


Lesenswert?

mysql schrieb:
> 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?

Falls es dieser ist
http://dev.mysql.com/doc/refman/5.1/en/connector-net-installation-windows.html
(mysql-connector-net-6.3.4-noinstall.zip)
dann sollte es reichen die MySql.Data.dll (mit) weiterzugeben.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

mysql schrieb:
> aber mein Problem ist nun ich habe das ganze Programm schon fertig

Ähm ... sorry, aber wenn das ein ernsthaftes Problem ist, solltest du 
mal über deinen Programmierstil nachdenken - sowas kapselt man doch! 
Genau genommen brauchst du nur ein Handvoll Funktionen:

- db_connect(server,dbname,pass) (oder connect-string bei odbc)
- db_close
- db_select(sql):xml
- db_error():string
- db_exec(sql)
- db_commit
- db_rollback

... und das wars. Da sollte es doch möglich sein, die konkrete Art der 
Verbindung dahinter zu verstecken ... ? Ich mache das jedenfalls so und 
auf diese Weise kann ich zwischen ODBC oder nativen Verbindungen zu 
MySQL, MSSQL und Oracle beliebig switchen, ohne am restlichen 
Programmcode etwas zu verändern. Genau genommen stecken die Unterschiede 
ausschließlich in der connect-Methode. Die liefert ein db_object, auf 
das sich alle Oprationen beziehen ...

von Peter (Gast)


Lesenswert?

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.

von koarl (Gast)


Lesenswert?

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

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

>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.

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.

>Auch kann man mit Datenbanken ein ganzes stück mehr mache, was ist mit
>preapared statements? Bulktransfers, setzen von autocommit und noch
>einiges mehr.

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 ...

Frank

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

von Peter (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

> 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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.