Umstieg MySQL auf MS SQL Server

[mkinzler]

Oder UniDAC, da dann sowohl MSSQL wie auch MySQL unterstützt wird.

[Bernhard Geyer]

Zitat von Neumann:

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

Halb-OT:
MS hat schon oft die Meinung geändert. Vor allem im Bereich DB-Zugriffsweg.
Hier alle Buzzwörter bezüglich "Das ist der beste Weg um auf Daten zuzugreifen (die ich kenne)...

ODBC
DAO
RDO
ADO
ADO.NET
ODBC


Das ist der Weg den Emba vorgeschlagen hat schon stabiler

BDE
<Ungewissheit> mit ein bischen ADO (dbBO) (bzw. TDataset ist eine gute Basis für 3th-Party-Kompos)
dbExpress
FireDAC

[Peter60]

Ich kann dir dringend Devart UNIDAC Tools empfehlen https://www.devart.com/unidac/ , da Borland/Codegear/Embarcadero immer wieder neue DB Tools angeboten hat. Danach war man gezwungen
seinen vorhanden Code immer wieder zu ändern was natürlich Zeit und Geld kostet. Daher nutzte ich seit Jahren schon die UNIDAC Tools. Ich verwende mehre Datenbanken (MSSQL/MySQL/SQLite) und kann in der Regel immer den gleichen Zugriff Code nutzten.

[Perlsau]

Zitat von mkinzler:

Oder UniDAC, da dann sowohl MSSQL wie auch MySQL unterstützt wird.

Stimmt, wenn man häufig mit unterschiedlichen DBMS arbeitet. Bei MsSQL und MySQL nehme ich noch immer dbGo, das reicht für mich, weil's da sowieso nur um private Projekte geht.

Muß man bei UniDAC nicht zusätzlich die Provider-Dateien erwerben? Ich erinnere mich nämlich noch daran, daß ich zuerst versehentlich bzw. aus Unkenntnis die Basic-Version der Unidac-Komponenten erworben hatte und danach feststellen mußte, daß ich damit gar nichts anfangen kann, weil die entsprechenden Provider fehlten. Hier im Forum gab man mir dann den Rat, ich solle versuchen, die umzutauschen, was DevArt auch anstandslos ohne Zusatzkosten gemacht hat, nachdem ich mein Dilemma erklärt hatte. Oder sind die Provider bei den Pro-Versionen alle dabei? Naja, egal, ich werde sie ja sowieso nicht erwerben.

[mkinzler]

Ja, bei der Pro sind die Provider dabei. Diesen müssten auch schon bei der Standard dabei sein:

https://www.devart.com/unidac/editions.html

Ich würde die Version mit Sourcen wählen.

[Bernhard Geyer]

Zitat von Perlsau:

Zitat von mkinzler:

Oder UniDAC, da dann sowohl MSSQL wie auch MySQL unterstützt wird.

Stimmt, wenn man häufig mit unterschiedlichen DBMS arbeitet. Bei MsSQL und MySQL nehme ich noch immer dbGo, das reicht für mich, weil's da sowieso nur um private Projekte geht.

Privat ist das keine Problem, aber bei Kommerzieller SW wärst du mit dbGO/ADO und MySQL in der GPL-Falle.

[Bambini]

Zitat von Bernhard Geyer:

Privat ist das keine Problem, aber bei Kommerzieller SW wärst du mit dbGO/ADO und MySQL in der GPL-Falle.

Was für eine GPL-Falle ist hier gemeint? Soweit ich weiß hat MySQL hat eine GPL, aber hat das etwas mit dbGO/ADO zu tun?

[haentschman]

Zitat:

aber hat das etwas mit dbGO/ADO zu tun?

...insofern das diese Komponenten mit der libmysql.dll arbeiten und das ganze dann in die GPL Falle fällt.

Lesestoff:
http://www.delphipraxis.net/163886-m...chtens-so.html

[mkinzler]

Bei dieser Zugriffart wird der Originalclient (Dll) von MySQL benötigt. Aus Sicht der Herstellers muss man diese lizensieren, wenn man sein Programm nicht unter die GPL stellen will. Die UniDAC-Komponenten (und sicherlich auch andere Alternativen) unterstützen auch direct access, also den Zugriff ohne diese Dll.

[p80286]

Zitat von 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?

Ich hab vor einiger Zeit ZEOS mal ausprobiert, war aber nicht unbedingt begeistert bzw. hab' ich keinen Vorteil gegenüber ADO/dbGo gesehen.


Gruß
K-H