Umstellung Paradox 7.0 auf Interbase

[CompData]

Hallo Leute!

Muss ein sehr großes Projekt von Paradox 7.0 auf Interbase umstellen.
Wie gehe ich das an, was muss ich beachten? Bitte um Hilfe.

Noch ein paar Infos:

- Entwicklungsumgebung: Win2k, Delphi 5.0 Ent., Seagate Crystal Reports

-für Anbindung der Tabellen sind Datenmodule eingerichtet;
Tabellen sind über Datasource bzw. Table-Komponenten angebunden

-Tabellenfelder sind als TFields im Datenmodul übernommen, sind dort zum Teil auch formatiert für Dateneingabe/Datenausgabe
-Edititeren der Daten erfolgt über DBEdit-Komponenten direkt im Formular

-Vom Programm berechnete Werte werden ganz normal über Edit/Post -Aufruf zugewiesen (Table.Edit; TableFELD.Value := ... ; Table.Post

[danielA]

Hallo CompData,

bin selbst gerade an einer ähnlichen Sache am kämpfen.

Also zuerst solltest du die Datenbank konvertieren, bevor du anfängst dein Projekt umzubauen. Dafür nimmst du am besten Datapump. Datpump schafft leider nicht alles alleine, da wirst du wohl noch selbst Hand anlegen müssen. Du solltest ebenfalls darauf achten noch keine Indizes, not Null Felder etc. in Interbase zu definieren. Das führt nach meinen Erfahrungen nur zu Problemen. Lass die Indizes usw. erst mal weg und definiere sie wenn du dein Projekt vollständig lauffähig hast. Boolsche Felder wandel am besten in VARCHAR[1] um, da es in Interbase keinen Boolschen Datentyp gibt.

Wenn du deine Datenbank konvertiert hast öffnest du dein Projekt und ersetzt alle TTable Objeke durch TIBTable (einfach durch CTRL+R in deinem Quelltext und dem des Formulars), fügst ein TIBDatabase Objekt hinzu und eine Koponente für die Transaktionskontrolle (TTransaction). Bei den TIBTable- Komponenten setzt du die Database auf dein TIBDatabase Objekt. Die TDatasource und TDBEdit-felder sollten unverändert mit TIBTable funktionieren.

es kann sein, daß du die Felder in die TIBTable neu einlesen mußt, da Groß- Kleinschreibung bei Interbase eine Rolle spielt. wenn du Feldnamen wie Index, Table ... hast, so müssen die umbenannt werden. Tabellen mit solchen Feldnamen können zwar erzeugt werden, die IBTable kann damit aber nicht wirklich was anfangen.
Achte in deinem Quelltext darauf, das es keine Boolschen Felder mehr gibt sondern diese jetzt vom Typ TStringField sein müssen.

Für Chrystal Reports benötigst du auf jeden Fall einen ODBC-Treiber, den kannst du hier http://www.ibphoenix.com/ibp_download.html#ODBC bekommen.

Solltest du mit dem Befehl <YourTable>.Flushbuffers arbeiten, den kannst du rausnehmen. Als alternative währe <YourIBTable>.Transaction.Commit zu nennen, achte aber darauf, das bei allen TIBTabellen, welche mit dieser Transaktion arbeiten, Active danach auf False gesetzt wird.

So das war jetzt mal das Gro was mir hierzu eingefallen ist.

Den Krieg hast du dann gewonnen, wenn du bei allen TIBTable Komponenten Active auf True setzen kannst.

Hast du mit den Chrystal Reports Komponenten schon unter Delphi 5 gearbeitet. Ich habe nur welche für Delphi 4 und die mußte ich zum Arbeiten mit Delphi 6 geringfügig umschreiben. Oder wo kann man die aktuellen herunterladen (habe bei Seagate leider nichts gefunden)?

Solltest du noch fragen haben so frag einfach

Grüße danielA

PS.: sieht wenig arbeit aus, ist es aber leider doch nicht :-(

[Lemmy]

Hi,

wie ich schon in einem anderen Forum auf diese Frage ausführlich geantwortet habe, würde ich auf keinen Fall die TIBTable einsetzen, da diese einfach nicht die Leistung besitzt und in einer Mehrbenutzerumgebung einfach Probleme macht. Besser ist da die TIBDataSet oder gleich auf andere Komponentenbibliotheken zurückgreifen (IBObjects oder FIBPlus).

Grüße
Lemmy

[FBrust]

Hallo,

noch mal ne Frage zu den Booleschen Feldern: Wie muss man sich das denn im Programm vorzustellen?

Muss man dann

Code:

if blTest then begin
....
end;

umwandeln in

Code:

if blTest = '0' then begin
...
end

?? (Wenn als Datentyp CHAR oder VARCHAR genommen wird)

Grüsse
Frank

[danielA]

Hallo FBrust,

die Frage kann man mit einem kurzen Ja beantworten :lol:

Grüße

danielA

[FBrust]

Hallo danielA,

ups, da sehe ich eine Menge Arbeit auf mich zukommen... :roll:

Danke für Deine Antwort

Grüsse
Frank

[Hansa]

Hi,

guck Dir mal das hier an :

http://www.auq.de/viewtopic.php?t=2719

Wie ich das sehe wirst Du so ähnliche Probleme kriegen. Für einige, die mit Sicherheit auftreten werden, steht da vielleicht schon die Lösung.

Was hier steht ist alles richtig, dennoch habe ich es auf anderem Wege gemacht : Ich habe die alten Daten erst einmal in eine Textdatei geschrieben und diese dann für Interbase wieder eingelesen. Alles andere war zu fehleranfällig. Indexe habe ich auch noch nicht, aber die NOT NULL Werte hab ich von Anfang an mitgeschleppt.

Soweit meine Erfahrungen. Na dann viel Vergnügen. :mrgreen:

Gruß
Hansa

[FBrust]

Hallo Hansa,

danke für den Tip (oder sollte ich sagen: die Tipp-Reihe?) :D

Wahrscheinlich mache ich es genauso: erst alles in Textdatei und dann wieder einlesen.

Und da meine Anwendung noch im Entstehen ist, kann ich ja ab sofort auf True und False verzichten (nur für den Fall, dass...), das spart schon mal Ärger (hoffe ich).


Bis dann
Frank

[Hansa]

Hi,

Zitat:

Und da meine Anwendung noch im Entstehen ist, kann ich ja ab sofort auf True und False verzichten

:!: Nur nicht. Du mußt erst einmal mit einem SQL-Script die Datenbank anlegen, läßt Du hierbei viele Felder aus, kriegst Du später Ärger mit Deiner Textdatei, die die Daten enthält. Schau Dier mein Bsp. an. Das ist eine Textdatei, die pro DS fast 700 Byte hat, in EINER Zeile. Die mußt Du in Delphi wieder auseinander nehmen und in diesem Falle auf ca. 70 Felder verteilen. Passiert dir ein Tippfehler in der Mitte, dann bist du dran. :dancer: Ich hatte z.B. die Bank in der DB als char (30) richtig angelegt, aber in der Textdatei aus Versehen als string [10] reingeschrieben. Folge : ab der Bank war ALLES verschoben und ich mußte den DB-string von hinten nach vorne wieder aufrollen. :bounce1:

Verzettele Dich nicht unnötig. Versuch zuerst einmal alle FELDER in die DB richtig rein zu kriegen, nicht die Daten. Und nicht mit Delphi ! Dann nimmste einfach mal CHAR (1) für die boolean-Felder.


Gruß
Hansa

[FBrust]

Hallo Hansa,

soweit bin ich noch garnicht. Mein Programm entsteht momentan auf Paradox-Basis. Ich bin nur auf dieses Thema gekommen, weil ich eine Update-Funktion entwickeln wollte, die per "ALTER TABLE..." Felder zu bestehenden Tabellen hinzufügen kann.

Dabei fiel mir auf, dass diese Vorgehensweise mit Booleschen Feldern nicht geht. Also möchte ich meine Tabellen so vorbereiten, dass später einmal, wenn (und falls) die Anforderungen steigen (z. B. C/S-System), ich mit "relativ wenig" (was immer das heissen mag) Aufwand umsteigen kann.

Und wenn ich später alle Booleschen Felder umstricken muss, kann ich es ja auch gleich erledigen, oder?


Grüsse
Frank