xsharp.eu

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

FFF wrote: ↑Mon Nov 13, 2023 10:45 am 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?

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

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

Ich habe vor einiger Zeit einen ganz anderen Ansatz gewählt:
-auf einer SQL-Datenbank (SQLSERVER) paralelle Tabellen erstellt
-mit C# eine Com/Ole-Komponente gebaut, diese spricht per ADO mit dem SQLserver
-in allen Updatefunktionen von Xbase/VO/... , genaugenommen in unlock wird der Datensatz in einen String verpackt, an das OleObjekt übergeben und dieses schreibt den dann auf den SQLserver. Aus Performancegründen in eine Übergabetabelle. Das geht in millisecunden
Auf dem SQLserver wird eine Sqlproc oder ein C# Programm gestartet, was den String aus der Übergabetabelle in die parallelen Tabellen verteilt.

Als Ergebnis des ganzen hat man eine komplett gespiegelte Datenstruktur mit sehr kleinem Zeitversatz, und kann nach Bedarf weiterhin mit Dbf's arbeiten oder die Vorteile von SQL nutzen

Jörg Bertram

Hallo Jörg,
ich habe seit ein paar Jahren was Ähnliches laufen, und habe das auch auf der Konferenz in München kurz gezeigt: bei jedem Update wird ein Datei mit dem Key in ein Verzeichnis.
Ein Windows-Service arbeitet dieses Verzeichnis dann ab und schreibt alle geänderten Sätze dann in die SQL-Tabelle.
Das mache ich eigentlich nur bei größeren Tabellen, wo per Filter gesucht wird.
Wolfgang