Migration xBase-Datenbanken zu SQL

[wriedmann]

Hallo Karl,
es ist ein Unterschied, ob es sich hier um ein einzelnes System handelt, oder um eine ganze Reihe davon.
Wenn man für so eine Migration ein 3rd-Party-Tool verwendet, gibt es immer Einstellungen, die man vergessen kann oder man vergisst eine Tabelle oder sonst was.
Zudem kann es sein, dass man bei einer Migration Daten anpassen/verändern will.
Daher ist es besser, man schreibt diese (definitiv nicht komplexe) Konvertierung selber, dann kann man sicher sein, dass sie immer gleich abläuft.
Wolfgang
P.S. ich habe sowohl DBConvert als auch Database.NET von Fish lizensiert und im Einsatz

[hilberg.it]

Jörg,
* Postgres ist sicher eine gute Idee, wenn Du die Wahl hast.
* das Migrieren der Tabellen ist vergleichsweise simpel.
* Das Problem ist die andere Kommunikation zwischen UI und der DB. Im Prinzip sollte der SQL-Rdd das "Verstecken".

Wenn es also nicht furchtbar "brennt", und wenn Du nicht scharf drauf bist, die Logik zwischen UI und DB neu zu schreiben, würde ich drauf warten. Und überlege Dir, ein "FOX" zu werden, dann kannst Du, sobald die Beta beginnt, mitspielen

Hi Karl,
weißt du mehr über den Release Plan der SQL-RDD? Wann soll es los gehen?

[wriedmann]

Hallo Jörg,
auf seinem Vortrag hat Robert was davon gesagt, dass die erste Beta dieses Jahr noch rauskommen soll, und die GA-Version Anfang 2024.
Sicherheitshalber würde ich davon ausgehen, dass das RDD ab Mitte Jahr weitgehend stabil sein sollte.
Das hängt aber auch stark davon ab, wie viele Leute das gleich implementieren und testen.
Einen ersten Prototypen davon gibt es schon.
Wolfgang

[mainhatten]

Hi Jörg,

zu beachten sind Blank Felder, insbesonders bei Date/DateTime Feldern.
SQL mag die so gar nicht -Abhilfe spezifisches Datum oder .null., wenn .null. sonst nicht verwendet.
IMO am besten explizit vorab unter xBase Wert weit in der Zukunft zuweisen und Code
hierzu erst einmal anpassen mit Mini-EmptyDate()-Funktion.

Wenn noch anstehend:
Ein Mittelweg könnte der Foxpro Upsizing Wizard sein.
Ausgehend von (Vfp-)Tabellen generiert der Upsize Scripts je nach gewähltem Backend.

Machen andere Tools wahrscheinlich auch, hier kannst Du in die Codegenerierung via Sourcecode vom Wizard eingreifen, da der vfp Quellcode dabei ist.

https://github.com/VFPX/UpsizingWizard
hat weiter fixes bekommen und ist immer noch als Source abrufbar, Target MS-SQL wurde von MS unter vfp9 damals mit getestet. PostGreSQL, MySQL und MariaDB wurden wohl am häufigsten nach MS-SQL eingesetzt.

Ich würde über Verwendung / Umstieg auf ein Data Dictionary nachdenken, wenn ihr im normalen Betrieb manchmal DB anpassen müsst. Bei einigen Kunden (Versicherung, Behörden) mit heftigen Feld- und Tabellenzahlen, mehr als 1 Index pro Table und vielen Referenzen spart das langfristig Arbeit - und die generieren Update-Scripte für die Kunden mit und bessere können auch migrieren - dann hast Du 2 Fliegen mit 1 Tool erwischt.

Deine Tabellenzahl liegt zwischen "auf jeden Fall" und "da muss ich wieder was Neues lernen"
In der Vfp-Welt waren da xCase und Stonefield DB-Kit die Platzhirsche,
aber es gibt auch einige Free Versionen unter Java, Dotnet und C.
In SQL Welt weit mehr "üblich" als unter xBase. Für jeden neuen Mitarbeiter, der das Datenmodell noch nicht auswendig kennt, ein Turbo zum Einarbeiten, da die Beziehungen sofort klar werden.

Man kann daraus gleich die SQL Anweisungen für Views, und Cursor generieren (RDD bestimmt auch) -
hängt von der bisherigen Erfahrung und Arbeitsweise des Coders ab, wie er schneller zum Ziel kommt.

YMMV & HTH
thomas