Umstieg von Paradox auf MySQL

[BK82]

Hallo,

ich habe eine Anwendung geschrieben, die als DB Paradox 7 nutzt. Nun möchte ich unter möglichst wenig Aufwand Paradox durch MySQL ersetzen. Ich benutze in meiner Anwendung TTable, TDataSource und TQuery. Und die Anzeige erfolgt über DBGrids, DBEdits und DBMemos.
Lässt sich Paradox da so einfach entfernen oder sind schon sehr grobe Einschnitte nötig? Und wenn ja, welche? Bzw. kann ich wenigstens die Anzeigeelemente belassen, so dass ich die DataSources über SQL "setze"?

DANKE!!! :-D

[uwewo]

Das einfachste wäre die Zeos Komponenten zu verwenden, da Du hier nur die TTable Komponenten ersetzen mußt.Vieleicht auch noch ein paar SQL scripte anpassen.

[mkinzler]

Die Anwendung ohne Anpassung der Datenhaltung ist nur bedingt zu empfehlen. Durch Anpassung der Datenbanks an die erweitereten Fähigkeiten eines DBMS ist mittelfristig sinnvoll.

[RavenIV]

Die Umstellung auf eine andere Datenbank wäre eine gute Gelegenheit für ein Redesign.
- Datenbank-Struktur anpassen
- Zugriff auf die Datenbank optimieren (TTable durch TQuery ersetzen)
- usw.

[BK82]

Ganz so einfach ist es mit den ZEOS Komponenten ja nun doch nicht oder? Welche würden denn die Tables ersetzen? Und müsste ich nicht dann auch sämtlich Anzeigeelemente auszauschen oder können DBGrids & Co mit ZEOS verbunden werden?

Ein Redesign soll nur die letzte Möglichkeit sein. Natürlich hier und da anpassen, aber ein ordentlich Redsign würde bedeuten das halbe Projekt neu zu schreiben und das will ich eigentlich nicht. Gibt es denn keinen schnelleren Weg? (Ich schätze mal 80% der Elemente des Projektes sind DB-Felder!) ... :(

[Thanatos81]

Die ZEOS sind Nachkommen von TDataSet, also zur Nutzung in Verbindung mit TDataSource geeignet. Und deine DBEdit, DBGrids, DNavigators & Co dürften ja über TDataSource laufen, oder?

Weiterhin sollte TQuery -> TZQuery und TTable -> TZTable relativ reibungslos funktionieren, empfehlen würde ich TTable-ähnliche Typen allerdings nicht, da die Tabelle ja komplett geladen wird. Lokal mag das OK sein, aber bei einem Client-Server-System nicht gerade optimal.

[RavenIV]

Zitat:

Zitat von Thanatos81

Weiterhin sollte TQuery -> TZQuery und TTable -> TZTable relativ reibungslos funktionieren, empfehlen würde ich TTable-ähnliche Typen allerdings nicht, da die Tabelle ja komplett geladen wird. Lokal mag das OK sein, aber bei einem Client-Server-System nicht gerade optimal.

darum sage ich ja: "TTable durch TQuery ersetzen". Gilt auch für ZTable.

Ist halt ein mittlerer Aufwand, weil man das DBGrid nicht direkt an eine Query hängen kann.

[mkinzler]

Zitat:

Ist halt ein mittlerer Aufwand, weil man das DBGrid nicht direkt an eine Query hängen kann.

Und Warum nicht?