Umstieg MySQL auf MS SQL Server

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

[mkinzler]

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

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