Umstieg MySQL auf MS SQL Server

[Lemmy]

sprich MySQL soll nicht grundsätzlich ersetzt werden sondern MS SQL als zusätzlich Datenbank eingebunden werden. Dann müsstest Du so was wie UniDAC einsetzen - oder eben bei Zeos bleiben. Zeos liegt für mich aber schon zu lange zurück als das ich dazu was sagen kann, aber hier findet sich bestimmt noch jemand...

[Bambini]

Ich verwende die ADO Komponenten (TADOConnection, TADOQuery usw.) für den Zugriff auf MSSQL.
Die wurde irgendwann in Delphi auf dbGo umbenannt. Funktionieren problemlos und schnell mit MSSQL und man benötigt keine Client DLL, da das Betriebssystem diese bereits mit bringen.

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

Gruß
K-H

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