Re: DB-Anwendung von MySQL 3.23 nach Firebird 1.5 portieren!?
- From: "hbcs@xxxxxx" <hbcs@xxxxxx>
- Date: 28 Mar 2006 11:05:57 -0800
Hallo Marian,
schön dass es dich "immer noch gibt" und du immer noch so ausführlich
hilfst - weltklasse!
Prima, das verheisst ja schon mal nichts Gutes..
Ich habe diverse Umstellungen dieser Art gemacht. Auch "härtere", wie
von BDE-Interbase nach ADO-Oracle, wobei mir heute noch der Schrecken
in die Glieder fährt wenn ich daran denke :-).
Dann baust Du eine neue Datenbank...
Die habe ich recht leicht, das klappt mit dem IBExport DataPump recht
gut. Muss zwar etwas Handarbeit ran, aber das sollte nicht das Prob.
sein. Notfalls über die Konvertierung der DB sogar die
Rechenzentrums-Leute.
Dein Fall klingt nach Cutover, also die neue neue Version verwendet die
neue DB, die MySQL-Version ist tot. Das ist der einfachste Fall.
Ja, so sieht es aus. MySQL stirbt mit Inbetriebnahme der FB-Version.
Das Rechenzentrum empfiehlt IBObjects als Komponenten. Ok?
Ja, OK. Aber vielleicht willst Du hier doch nach Zeos gucken.
Bin mir da eben nicht schlüssig. Kommt unten gleich nochmal.
Ich hab bei GExperts eine "Replace Component" Funktion gesehen, klappt
das Ersetzen damit?
Das funktioniert, ist aber fehleranfällig weil es keine Rückmeldung darüber
gibt was geklappt hat und was nicht. Die Ersetzung passiert dabei innerhalb
der IDE, ist also irgendwie zu sehr am "lebenden Objekt". Insbesondere
Ereignishandler und Verbindungen zu anderen Komponenten bleiben gerne auf
der Strecke und es ist knifflig solche Verluste sofort festzustellen.
Das verstehe ich. Wäre ja auch zu schön gewesen... *seufz*
Ich gehe daher meist anders vor: Speichere alle Formulare als Text falls
das nicht ohnehin geschehen ist. Dann kannst Du einfach global in DFM- und
PAS-Dateien per Suchen&Ersetzen Klassennamen austauschen. Holzhammer.
TextPad kann das zum Beispiel sehr schön.
Wenn Du danach in der IDE ein Formular oder Datenmodul mit den neuen
Klassen öffnest, so wirst Du über unbekannte Eigenschaften oder solche
mit falschen Werten informiert. Du solltest die Meldungen alle lesen und
überlegen ob sie für Deine Anwendung wesentlich sind (bei den ersten zwei
Formularen, weitere kannst Du dann natürlich etwas flotter abhandeln).
Falls ja kannst Du jetzt noch in den (Text-)DFMs per Suchen&Ersetzen oder
kreativem Einsatz von RegExprs nachbessern. Du speicherst in der IDE NICHT,
sondern machst das Formular/Datenmodul nach den externen Änderungen neu
auf.
Ok, klar. Umständlich, aber scheint der "sichere" Weg zu sein.
Danach versuchst Du wieder zu übersetzen. Hierbei findet der Compiler all'
die Stellen im Code an denen die alten und neuen Klassen formal nicht
zusammenpassen, die musst Du natürlich anpassen und dabei ist es günstig
wenn die neuen Komponenten und die alten aus dem selben Stall kommen.
Es ist dann nämlich wahrscheinlicher, daß dieselben Operationen existieren
und auch gleich heißen.
Das spricht dann eben doch für Zeos, eindeutig. Ab "wann" kann ich das
dann gleich in der IDE testen und kann mir den Umweg über den externen
Texteditor sparen? Wenn die Klassennamen angepasst sind?
Schlimmstenfalls musst Du an einer Million Stellen etwas wie
ParamByName['Dings'].AsInteger:=1
durch
Parameters.ByName['Dings'].AsInteger:=1;
ersetzen. Lästig, aber überlebbar da durch den Compiler entdeckt[1].
Wenn das Programm wieder übersetzbar ist lässt Du es laufen.
Nein. Dann mach ich erst mal das erste Fass auf ;-)
Die ersten
Schritte sind dann normalerweise die Anpassung der Datenbankverbindungsdaten,
die sind irgendwie im Programm einstellbar oder festkodiert oder werden aus
einer Konfiguration gelesen. Das ist eine Codestelle die in jedem Fall
angepasst werden muss.
Wenn die Anwendung dann läuft und mit der neuen Datenbank redet fängst Du
an Deine Testsuite durchzuackern. Probleme, die dabei auftreten, bearbeitest
Du mit den "normalen" Debugging-Methoden und wenn das Ergebnis dann nur die
neue DB können soll kannst Du hier auch beliebige Lösungen anwenden die dem
neuen System angemessen erscheinen.
Ja, das kommt dann sicher dazu. Natürlich gäbe es so einiges, was man
inzwischen mit feinen Triggern und UDFs lösen könnte, aber das lohnt
sich wohl nicht, die Anwendung ist relativ statisch, da kommt nichts
neues mehr dazu.
Das Thema ist ein weites Feld, aber das wäre so in etwa der Anfang. Ich meine
die Testverfahren sind wichtig. Du solltest eine gute Kenntnis der aktuellen
Version haben (aus Anwendersicht: Was tut das Programm?), und es ist gut wenn
sie während der Arbeit lauffähig zum Vergleich vorliegt.
Ja, allein schon wegen der verschiedenen SQL-Dialekte, da wirds ja
einige Haken geben. Na gut. Ich sehe, das ist ein ganz schöner Batzen
Arbeit, der da wartet...
Auf jeden Fall schon mal vielen lieben Dank für die Infos!
LG, Heiko.
.
- Follow-Ups:
- Re: DB-Anwendung von MySQL 3.23 nach Firebird 1.5 portieren!?
- From: Marian Aldenhövel
- Re: DB-Anwendung von MySQL 3.23 nach Firebird 1.5 portieren!?
- References:
- DB-Anwendung von MySQL 3.23 nach Firebird 1.5 portieren!?
- From: hbcs@xxxxxx
- Re: DB-Anwendung von MySQL 3.23 nach Firebird 1.5 portieren!?
- From: Marian Aldenhövel
- DB-Anwendung von MySQL 3.23 nach Firebird 1.5 portieren!?
- Prev by Date: Re: Firebird und Internet
- Next by Date: Re: DB-Anwendung von MySQL 3.23 nach Firebird 1.5 portieren!?
- Previous by thread: Re: DB-Anwendung von MySQL 3.23 nach Firebird 1.5 portieren!?
- Next by thread: Re: DB-Anwendung von MySQL 3.23 nach Firebird 1.5 portieren!?
- Index(es):
Relevant Pages
|
