Umstieg MySQL auf MS SQL Server

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

[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

[Neumann]

Hat mich auch gewundert mit dem ODBC, aber MS sagt das ist der richtige Weg und die sollten es eigentlich wissen.

Ob jetzt Zugriff auf MYSQL oder Firebird über ODBC ev. nicht so gut funktioniert spielt eigentlich keine Rolle; dort ist ODBC eine zusätzliche Zwischenschicht die natürlich Probleme bereiten kann.

[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?

[jobo]

Zitat von teebee:

Trotzdem irgendjemand hier, der für MSSQL ZEOS benutzt, bzw. aus bestimmten Gründen nicht?

Mal sehen, wer antwortet. Ich gehöre nicht dazu, spielt aber hier keine Rolle.
Mein Tipp wäre, das macht selten jemand, weil die Komponenten eben im Open Source bereich angesiedelt sind.

[Perlsau]

Zitat von teebee:

Trotzdem irgendjemand hier, der für MSSQL ZEOS benutzt, bzw. aus bestimmten Gründen nicht?

Vor vielen Jahren hatte ich mal Zeos im Einsatz, damals waren diese DB-Komponenten noch unidirektional, keine Ahnung, ob das immer noch so ist. Wenn du herausfinden willst, ob Zeos auf irgend eine Weise dbGo überlegen ist, mach doch einfach mal ein paar Tests mit einer Testanwendung und einer Test-Datenbank. Ich verlasse mich nur selten auf die Aussagen anderer, wenn ich die Möglichkeit habe, selbst zu untersuchen und zu vergleichen.

Die Komponenten von DevArt kann ich ebenfalls empfehlen. Ich hab mir für Firebird die Basic-Variante von IbDac besorgt, die ist ohne Quellcode und kostet damals wie heute 100 US-Dollar. Für dich wäre dann wohl SDac die entsprechende Komponentensammlung.

... und nein, ich erhalte keine Provision, sondern empfehle das nur deshalb weiter, weil ich die Devart-Komponenten für die besten am Markt halte ... selbstverständlich neben FireDac, das aber für Benutzer älterer Delphi-Versionen nicht zur Verfügung steht.