Umstieg MySQL auf MS SQL Server

[Bernhard Geyer]

Zitat von p80286:

Ado ist für MS-SQL auf jeden Fall eine (nicht schlechte) Möglichkeit. Aber Du solltest bedenken, daß ADo in der Zwischenzeit ein totes Pferd ist, zumindest solange MS nicht wieder seine Meinung ändert.

Soweit ich verstanden habe ist nicht ADO das tote Pferd sondern "nur" der OLE/DB Provider für den MS SQL-Server.
Der native Client für den MS SQL-Server soll davon unberührt sein. Und natürlich auch ADO.NET bzw. der .NET Provider.

[Bbommel]

Das mit dem (halb-)toten Pferd würde mich auch mal näher interessieren. Ich nutze ADO für den lesenden und schreibenden Zugriff auf MS SQL seit Jahren und bin damit sehr zufrieden. Als Provider steht hier allerdings auch

Delphi-Quellcode:

  
Result.Provider:='SQLOLEDB.1';

Da bisher auch bei aktuellen Windows-Versionen alles problemlos funktioniert, sind ja wahrscheinlich keine hektischen Aktivitäten nötig, aber was genau wäre denn zu tun, wenn das Pferd endgültig erschossen wird? Wo bekäme ich denn diesen nativen Provider für MS SQL her? Oder ist der bei Windows auch immer mit an Bord?

Viele Grüße
Bommel

[mkinzler]

Sollet Teil der Clientinstallation sein

[Bbommel]

Hm, ich bin ein bisschen verwirrt - vielleicht liegt es aber auch daran, dass die Begriffe etwas durcheinander gehen. Wenn ich nach MS SQL Client suche, dann lande ich z.B. auf dieser Seite hier von Microsoft:
https://msdn.microsoft.com/de-de/sql.../aa937733.aspx
(Interessanterweise führt der erste Google-Treffer nur zu dieser Seite, auf der nur vom SQL Server 2005 und 2008 die Rede ist, sucht man aber explizit z.B. nach SQL Server 2012 Client, so landet man beim "Feature Pack", das neben vielen anderen Dingen dann ebenfalls einen aktualisierten Native Client enthält).

Auf der Erklär-Seite dazu steht dann, dass dieser Native Client einen Zugriff über OLE DB oder über ODBC (und damit in beiden Fällen wiederum über ADO) bereitstellt. Als totes Pferd wird in dem Text dort eigentlich nur die standardmäßig bei Windows mitgelieferten MDAC-Geschichte genannt, die auf dem Stand von 2000 eingefroren wird.

Dann habe ich noch folgendes gefunden:
https://www.microsoft.com/de-de/down....aspx?id=35580

Das scheint zu bedeuten, dass zukünftige Versionen des Native Clients keine OLE DB-Schnittstelle mehr liefern werden, sondern nur die ODBC-Schnittstelle.

Letztlich müsste das für eine auf ADO basierende Anwendung aber ja auch egal sein, weil man mit ADO auch problemlos auf ODBC zugreifen kann. Man müsste also dann nur den ConnectionString austauschen und könnte problemlos weiterhin mit dem SQL Server arbeiten. Damit sollte man doch auch jetzt also eigentlich noch problemlos auf die ADO-Geschichten in Delphi setzen können (was ja vielleicht auch für den OP noch wichtig ist), oder?

Habe ich da jetzt alles soweit richtig verstanden? Ich lasse mich gerne korrigieren, denn manchmal schwirrt mir bei den ganzen Datenbank-Zugriffsschichten etwas der Kopf.

[Lemmy]

Hallo,

ich kann zu MS SQL nichts beitragen, möchte aber meine Erfahrung zum Thema ADO - ODBC - MySQL hier einbringen:

Ich habe eine Anwendung von ADO - ODBC - MySQL auf Devart (MyDAC) umgestellt und damit eine ca. 15% Performancesteigerung erreicht - bei einzelnen SQL-Abfragen lag die Steigerung im Spitzenwert bei gut 30-40%

Daher würde ich die ADO - ODBC - Irgendwas Bridge als Notlösung akzeptieren, aber nicht als was dauerhaftes. Davon abgesehen dass zumindest bei MySQL 5.1 die ODBC Treiber auch so ihre Tücken haben....

[Bbommel]

Zitat von Lemmy:

Ich habe eine Anwendung von ADO - ODBC - MySQL auf Devart (MyDAC) umgestellt und damit eine ca. 15% Performancesteigerung erreicht - bei einzelnen SQL-Abfragen lag die Steigerung im Spitzenwert bei gut 30-40%

Daher würde ich die ADO - ODBC - Irgendwas Bridge als Notlösung akzeptieren, aber nicht als was dauerhaftes. Davon abgesehen dass zumindest bei MySQL 5.1 die ODBC Treiber auch so ihre Tücken haben....

Für MySQL mag das tatsächlich ein Problem sein. Als ich das früher mal benutzt habe, war ich davon auch nicht rundum begeistert. Microsoft selbst sieht in einer FAQ zur SQL Server-Anbindung (https://msdn.microsoft.com/en-us/sql.../aa937707.aspx) keine Probleme und eigentlich auch kaum einen Unterschied zwischen ODBC und OLE DB.

MS sagt recht selbstbewusst:

Zitat:

Q. ODBC is a "wrapper" API and is inherently inefficient, right?

A. This may be true for some ODBC drivers, but not for SQL Server Native Client. ODBC in SQL Server Native Client and also in MDAC is a true native API for SQL Server.

Naja, müsste man mal testen. Auf jeden Fall läuft bei mir ADO->OLE DB->MS SQL sehr performant (und die Probleme, die ich mal hatte, waren alle von mir selbst verursacht - falsche Cursor-Location und so - und hier in der DP wurden die immer gelöst).

[teebee]

Vielen Dank für die Hinweise, ich denke ich werde es mit den ADO-Komponenten machen, habe ich ja an Bord. Erste Versuche waren ganz vielversprechend.
Trotzdem irgendjemand hier, der für MSSQL ZEOS benutzt, bzw. aus bestimmten Gründen nicht?

[Neumann]

Ja genau richtig.

Zugriff über die ADO bzw DBGo-Komponententen auf den ODBC-Treiber des MSSQL. Geht sowohl Lokal, im Lokalen Netz und auch wenn der MSSQL-Server über Internet erreichbar ist.

[Bambini]

Zitat von Bbommel:

Das scheint zu bedeuten, dass zukünftige Versionen des Native Clients keine OLE DB-Schnittstelle mehr liefern werden, sondern nur die ODBC-Schnittstelle.

Da die "alten" OLEDB Treiber für MSSQL bereits das Betriebssystem mitbringt, kann man vermutlich recht lange auf den MSSQL zugreifen, sofern man keine Features wir z.B. besondere Spaltentypen der neuen MSSQL Server verwendet.

Ob das uralte ODBC wirklich die beste Wahl ist? Ich bin da skeptisch.

[mkinzler]

Zitat:

Ob das uralte ODBC wirklich die beste Wahl ist? Ich bin da skeptisch.

ODBC wird aber wieder weiterentwickelt