Umstieg MySQL auf MS SQL Server

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

[Bernhard Geyer]

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

Wir haben bei unserer Lösung die letzten BDE-Reste vor ca. 12 Jahren entsorgt und setzen auf TDataset-Nachfolger + Bridge-Pattern.
Sollte der Lieferant für eine Komponeten nicht mehr sein (bzw. Entwicklungstechnisch mist bauen) wird die eine Bridgepattern-Klasse angepasst und gut ist.
Aktuell würden wir bei den (Noch-Nicht DevArt)-DB-Zugriffskomponenten wenn es nötig sein würde auf DevArt umschwenken (wie vor Jahren bei MySQL geschehen).

[jobo]

Zitat von Dejan Vu:

Springt ihr echt immer auf den neuesten Zug auf?

Nein, eben nicht. Das ist ja der Grund, warum ich Delphi vorziehe. Es ist nicht nötig und es ist kein Zufall. Zumindest vermute/hoffe ich, dass es auch was mit der Strategie des Unternehmens zu tun hat.
Wir haben auch nur BDE/ADO eingesetzt (ohne Drittanbieter).

[OT]
Mal so eine Frage an die Spezialisten:
Kennt jemand Hinter-)Gründe für den neuerlichen Schwenk auf ODBC? Wenn es da was handfestes gibt, brauch ich mir keine Verschwörungstheorie auszudenken.
[/OT]

[Bernhard Geyer]

Zitat von jobo:

[OT]
Mal so eine Frage an die Spezialisten:
Kennt jemand Hinter-)Gründe für den neuerlichen Schwenk auf ODBC? Wenn es da was handfestes gibt, brauch ich mir keine Verschwörungstheorie auszudenken.
[/OT]

"Offizelle" Hintergründe?
Ich würde sagen das sie mit der Properitären Technik ADO(.NET) mittlerweile Problem haben da der "rest" der Welt auf ODBC setzt.
Und nachdem ja die aktuelle Firmenstrategie ist offener gegenüber Standardschnittstellen zu sein ist passt ein aktivere ODBC-Support zu dieser Strategie