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
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.
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?
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.
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 ...
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
>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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.