Umstieg MySQL auf MS SQL Server

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

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

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 von Bernhard Geyer:

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

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

Gruß
K-H

[jobo]

Zitat von p80286:

Zitat von Bernhard Geyer:

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

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

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 von jobo:

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 von jobo:

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 von Bernhard Geyer:

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 von Bernhard Geyer:

Zitat von jobo:

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