Umstieg MySQL auf MS SQL Server

[teebee]

Hallo zusammen,

ein Projekt, das bisher auf eine MySQL-Datenbank im LAN zugreift, soll jetzt auf den MS SQL Server umgestellt werden.
Den Zugriff auf MySQL hatte ich mit den ZEOS-Komponenten unter Delphi 6 Pro bewerkstelligt. Ein neueres Delphi steht leider nicht zur Verfügung.

Welche Komponenten würdet Ihr mir für den Zugriff auf den MS SQL Server empfehlen?
Wäre es vernünftig bei ZEOS zu bleiben? Sollte ich besser andere Komponenten verwenden? Am liebsten natürlich freie, es sei denn, es gibt kommerzielle Komponenten, die den Zugriff so einfach machen und so viel besser sind, dass es sich wieder lohnen könnte.

Wäre Lazarus vielleicht auch eine sinnvolle Option, dort sind ja auch DB-Komponenten dabei?
Plattformunabhängigkeit ist allerdings kein Thema, das Projekt wird ausschließlich unter Windows eingesetzt.

Danke für Vorschläge,
teebee

[Lemmy]

Zitat:

Zitat von teebee (Beitrag 1322299)

ein Projekt, das bisher auf eine MySQL-Datenbank im LAN zugreift, soll jetzt auf den MS SQL Server umgestellt werden.

Verrätst Du uns auch warum? Zumindest mich würde es sehr interessieren.

Komponenten: Ich nutze jetzt seit ein paar Jahren DevArt, für MSSQL gibt es SDAC und die Preise sind völlig OK.

GRüße

[teebee]

Danke Dir schon mal.

Das Projekt soll in einem Betrieb eingesetzt werden, in dem bereits der MSSQL-Server vorhanden ist, die dortige IT möchte keinen zusätzlichen DB-Server wg. Einrichtung, Pflege und Backup.

Da ich ja schon ZEOS im Einsatz habe, interessiert mich natürlich vor allem, ob ich sinnvollerweise dabei bleiben kann, oder ob das speziell für MSSQL Blödsinn wäre. Inwiefern wären denn z.B. die SDAC besser/zuverlässiger?

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

[Neumann]

ODBC - ADO funktioniert auch; habe ich mal in einer allerdings rel. einfachen Anwendung eingesetzt.

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

Zitat von p80286 (Beitrag 1322402)

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

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

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:

Zitat von Lemmy (Beitrag 1322462)

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:

Zitat von teebee (Beitrag 1322477)

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:

Zitat von teebee (Beitrag 1322477)

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.

[Bernhard Geyer]

Zitat:

Zitat von Neumann (Beitrag 1322467)

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:

Zitat von mkinzler (Beitrag 1322509)

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:

Zitat von Perlsau (Beitrag 1322545)

Zitat:

Zitat von mkinzler (Beitrag 1322509)

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:

Zitat von Bernhard Geyer (Beitrag 1322570)

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:

Zitat von teebee (Beitrag 1322477)

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

[TRomano]

Provider muss man bei UniDAC nicht extra linzensieren, sie sind für die wichtigsten DBMS enthalten.
Ich musste auch bei einem Projekt der Stadt Lübeck UniDAC einsetzen, damit die nicht mit der Software in diese Lizenz-Falle (das ist noch ein nettes Wort) tappen. Dazu muss allerdings der Direct Access-Mode in den Options angeschaltet werden.
Das ganze Hin & Her bei MS und Borland/Emba habe ich auch nicht mitgemacht. UniDAC habe ich seit mehreren Jahren im Einsatz und abgesehen von einigen (auch kritischen) Bugs läuft es ganz gut. Die kritischen Bugs werden auch relativ schnell behoben und das DevArt-Forum ist ebenfalls hilfreich.

[Peter60]

Wenn du professionell arbeitest dann solltest du auch Profiprodukte einsetzen dann sind zukünftige Entwicklungen garantiert.
Bei GPL u.ä. ist mit einem Abruch der Weiterentwicklung immer zu rechnen. Das Lehrgeld musste ich auch schon zahlen.

[jobo]

Zitat:

Zitat von Peter60 (Beitrag 1322580)

Wenn du professionell arbeitest dann solltest du auch Profiprodukte einsetzen dann sind zukünftige Entwicklungen garantiert.
Bei GPL u.ä. ist mit einem Abruch der Weiterentwicklung immer zu rechnen. Das Lehrgeld musste ich auch schon zahlen.

Naja, ob das durchgängig so gemacht wird? Was ist dann mit Firebird oder Postgres oder jedis?

Ich denke, wenn man auf Wunsch des Kunden von einer freien DB auf MS SQL wechselt, ist der Wechsel auf den (hauseigenen) Treiber von MS auch naheliegend. Und, der Kunde muss sich der Kosten bewusst sein, die er ja offenbar eh bereit ist zu tragen.

Kunden die dagegen schon an der Datenbank sparen wollen, wollen dies mglw. auch bei den Zugriffskomponenten, dann wäre man bei ZEOS. Das sind m.E. eher natural fits. Diese Paarungen werden wahrscheinlich recht häufig eingesetzt und dürften daher auch robuster sein.

Dass sich professionelle Komponenten auszahlen können, konnte man hier ja neulich "live" mitverfolgen(war das nicht devart?). Bei MS Treibern würde ich meine Hoffnung allerdings eher auf den Reifegrad legen, denn auf schnelle Bugfixes.

[Bernhard Geyer]

Zitat:

Zitat von Peter60 (Beitrag 1322580)

Wenn du professionell arbeitest dann solltest du auch Profiprodukte einsetzen dann sind zukünftige Entwicklungen garantiert.
Bei GPL u.ä. ist mit einem Abruch der Weiterentwicklung immer zu rechnen.

Auch bei Profiprodukten kann das passieren. Wie viele Techniken hat MS im einen jahr als DIE ZUKUNFTTECHNIK angepriesen und nächstes Jahr als WER DAMIT ARBEITET IST SELBST SCHULD.
Bei GPL (bzw. OpenSource bzw. Quelltext vorhanden) kannst du ja das selbst noch etwas am Leben erhalten.

[p80286]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1322596)

Wie viele Techniken hat MS im einen jahr als DIE ZUKUNFTTECHNIK angepriesen und nächstes Jahr als WER DAMIT ARBEITET IST SELBST SCHULD.

:stupid: Das gibt es? Kann ich mir üüüberhaupt nicht vorstellen!:stupid:

Gruß
K-H

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1322608)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1322596)

Wie viele Techniken hat MS im einen jahr als DIE ZUKUNFTTECHNIK angepriesen und nächstes Jahr als WER DAMIT ARBEITET IST SELBST SCHULD.

:stupid: Das gibt es? Kann ich mir üüüberhaupt nicht vorstellen!:stupid:

Bernhard hatte ja schon auf der vorigen Seite die Datenzugriffstechniken von MS angerissen. Ich find's zum k... auch wenn ohne diese Dinge Eskapen die Hälfte von uns wahrscheinlich arbeitslos wäre.
Solche Geschichten waren für mich immer ein guter Grund, auf Delphi zu setzen. Die haben da etwas Kontinuität reingebracht.

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1322610)

Bernhard hatte ja schon auf der vorigen Seite die Datenzugriffstechniken von MS angerissen. Ich find's zum k... auch wenn ohne diese Dinge Eskapen die Hälfte von uns wahrscheinlich arbeitslos wäre.

Oder man setzt auf DesignPattern und es ist egal was sich hinter der Fassade/Brücke und Co. ändert ...

Zitat:

Zitat von jobo (Beitrag 1322610)

Solche Geschichten waren für mich immer ein guter Grund, auf Delphi zu setzen. Die haben da etwas Kontinuität reingebracht.

Delphi hat aber auch im Webumfeld (PageProducer und Co.) oder bei den Frameworks (VCL -> CLX -> VCL.NET -> FMX) eine bewegte Vergangenheit :-)

[Bambini]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1322613)

Delphi hat aber auch im Webumfeld (PageProducer und Co.) oder bei den Frameworks (VCL -> CLX -> VCL.NET -> FMX) eine bewegte Vergangenheit :-)

und auch Bold, das Entity Design Tool. Nach einer immensen Werbetour -> dead.
Daher ist es auch bei Delphi ratsam nicht gleich auf die neuen Dinge zu setzen. Diese reifen erst über Jahre/Versionen und werden nicht fertig bzw. sterben vorher.

[jobo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1322613)

Zitat:

Zitat von jobo (Beitrag 1322610)

Solche Geschichten waren für mich immer ein guter Grund, auf Delphi zu setzen. Die haben da etwas Kontinuität reingebracht.

Delphi hat aber auch im Webumfeld (PageProducer und Co.) oder bei den Frameworks (VCL -> CLX -> VCL.NET -> FMX) eine bewegte Vergangenheit :-)

Ja, auch im Bereich Reporting (..) kann ich mich an blöde Sachen erinnern..

Wie auch immer, bei MS sehe ich eher den Trieb, neue oftmals unausgegorene Sachen auf den Markt zu werfen, Hauptsache Entwickler Heerscharen müssen wieder den nächsten MCSE machen und man kann der EDV Abteilung wieder was Neues verkaufen.

Gegen eine seriöse Weiterentwicklung ist ja auch gar nichts einzuwenden, aber ich hab dauernd das Gefühl, dass sie die falschen Zöpfe abschneiden.

[Dejan Vu]

Springt ihr echt immer auf den neuesten Zug auf? Ich verwende ADO seit Jahrhunderten (gefühlt), ohne Probleme. Gut, die neuen Datentypen schafft das Teil nicht, aber es reicht.

Mit BDE bin ich also in bald 20 Jahren Delphi-Entwicklung bei 2 Providern gelandet. Das nenn ich jetzt nicht unbedingt problematisch. Ich musste auch nicht ständig den MCSE machen oder einer IT-Abteilung neue Sachen verkaufen (bzw. selber einkaufen)

Persönlich bin ich ein großer Freund von guten Drittanbietern, die auch gerne etwas kosten können. Aber bloß weil UniDAC nun heute das Richtige ist, weiß man doch auch nicht, was in 10 Jahren ist, oder?

Ein kleines Risiko ist schon dabei, aber wenn man etablierte Komponenten ('mature') nimmt, dann ist das Risiko doch recht klein, irgendwann umsatteln zu müssen. Aber selbst das war bei einem 200k LOC-Projekt kein großes Ding (BDE=>ADO).