xsharp.eu

I wrote this many years ago. Never fully implemented because I couldn't get everything to work in VO.

https://joecurran.net/advice/dbf_to_sqlite.htm

My strategy was to move the DBFs to a text/csv format and then import into the SQL flavor of your choice.

Hallo Jörg,

comitas2 wrote: ↑Mon Nov 13, 2023 2:29 pm Es wird aber wahrscheinlich nicht mehr praktikabel zu sein, wenn die SQL-Datenbank in der Cloud arbeiten soll?

Wie Wolfgang richtig bemerkt hat, arbeiten wir mit ADO.NET, was uns die Unterstützung von Azure SQL (sowie allen Arten von SQL Server, einschließlich kostenlosem Express und LocalDB) ermöglicht. Tatsächlich gibt es zwischen unserer Anwendung und ADO.NET eine Schicht in Form unserer eigenen speziellen statischen Klasse, die die Wiederholungslogik für Übertragungsfehler unterstützt. Aber es ist nicht nur Cloud-Unterstützung erforderlich. Es kann beispielsweise ein Fehler wie Deadlock vorliegen. Es kann (und sollte) einfach durch einen Neustart des Vorgangs (eine Reihe von Anforderungen) umgangen werden. Das heißt, solche Fehler sollten die Anwendung nicht „zerstören“.

Hallo Joe und Leonid,
Danke für Eure Anmerkungen. Gerade auch den Artikel "https://joecurran.net/advice/vo_sqlite.htm" finde ich hilfreich.
Weitere Code-Beispiele sind Willkommen.
Gruß Jörg

Code habe ich nicht für Dich. Aber schau Dir Database.Net an (https://fishcodelib.com/Database.htm) - Einmallizenzkosten. Habe ich seit x-Jahren, der Mann in Taiwan bringt regelmäßig Updates für lau. In der kostenpflichtigen Version ist das Umziehen von Quelle zu Ziel DB System ein paar Klicks, inkl. der Indexe und Typkonvertierungen, drin. Spart Zeit und Nerven. Alternativ gibt es die DataMigration separat, aber ich mag das DB.Net, weil man alles mögliche ad hoc damit machen kann.

Dieses OpenSource Projekt sieht recht vielversprechend aus https://github.com/yellowfeather/DbfBulkCopy Und es bekommt aktuelle Commits.

Hallo Karl und hilberg.it,
Danke für den Hinweis auf das Tool und das Git-Beispiel. Ich werde es mir anschauen.
Gruß Jörg

Hallo zusammen,
sorry, nur zur Klärung: geht es um die einmalige Migration der Daten oder um die Portierung der Applikation?
Das einmalige Migrieren der Daten würde ich auf keinem Fall einem Tool überlassen, sondern lieber selber schreiben...und verglichen mit dem Portieren der Applikation ist das einfach.
Wolfgang

Hallo Wolfgang,
pro Kunde wäre es eine einmalige Migration bei Update-Kauf. Jedoch muss dazu auch noch die Applikation portiert werden, ehe ein Update angeboten werden kann.
Gruß Jörg

Hallo Jörg,
in diesem Fall (mehrere Kunden) bist Du auf jeden Fall gut beraten, die Migration der Daten von DBF nach SQL selbst zu implementieren und gründlich zu testen, bevor die Kunden damit arbeiten.
Wolfgang

Wolfgang,
darf man fragen, warum? Die Wahrscheinlichkeit, dabei einen „Hund“ zu übersehen, erscheint mir größer, als das ein Tool, das seit Jahren von vielen Leuten benutzt wurde, fundamentalen Mist baut…