Probleme nach der Portierung von ORACLE nach Interbase

[Paul Ottenjann]

Hallo zusammen,

habe bei der Portierung von Oracle-Tabellen/-Views etc. mit Datapump in eine Interbase-DB folgende Probleme:

Die unter Oracle vorhandenen Views werden nicht als View sondern als Tabellen in der Interbase-DB angelegt (liegen in der Interbase-DB nach dem "Datapump" unter der Rubrik "Tabellen" vor). Wenn ich nun diese Views auf der Interbase-DB mit dem SQL-Explorer von Hand anlegen (Syntax ist ein wenig anders als unter ORACLE - hat aber dann irgendwann funktioniert), dann werden die Views unter Rubrik "Ansichten" angelegt. Die durch Datapump erstellten gleichnamigen Tabellen müssen allerdings vorher gelöscht werden. Im "sql-Explorer" sieht soweit alles gut aus. Wenn ich auf die jeweiligen Views zugreife, werden auch die aktuellen Daten angezeigt.
Wenn ich nun über das Delphi-Programm zugreife (BDE-Änderungen etc. vorgenommen), erhalte ich eine Exception der Klasse EDBEngineError, Meldung: 'Allgemeiner SQL-Fehler arithmetic exception, numeric overflow, or string truncation Cannot transliterate character betwenn character sets'.
An den Programmsourcen habe ich keine Änderung vorgenommen. Lediglich bei "TDatabase" den entsprechenden "Alias" für die Interbase-DB eingebunden.
In der BDE benutze ich den Nativ-Treiber "INTRBASE" 4.0, als LANGDRIVER habe ich unter "System-INIT" 'ascii ANSI' vorbelegt.
Bei diesen Einstellung zeigt mir der "sql-Explorer" die Daten ohne Fehlermeldung an.
Ändere ich bei diesen Voreinstellungen nun den LANGDRIVER beim Native-Treiber "INTRBASE" (in der BDE unter Konfiguration) auf beispielsweise 'ascii ANSI' oder den "Alias" (bei der BDE unter Datenbanken) von leer auf 'ascii ANSI', so erhalte ich bereits mit dem "sql-Explorer" die o. a. Fehlermeldung.

Benutzt wird die BDE 5.01 (lt. Info zur BDE-Verwaltung). Die Versionsnummern belaufen sich unter den BDE-Versionshinweisen allerdings überwiegend auf 5.1.1.

Was könnte nun die Ursache sein und wo setze ich da an?

Vielen Dank!

[Torsten Grundke]

Hallo Paul,

welcher "Character Set" wurde denn als Default-Character-Set für die Datenbank definiert?

Im deutschen Sprachraum bietet sich ISO8859_1 an.

Tschau

Torste

[Paul Ottenjann]

Hallo Thorsten,

herzlichen Dank für die Info.
Hatte darüber auch schon gelesen. Habe allerdings noch nicht herausgefunden, wo man den "Charakter Set" nachträglich einstellen kann?

Gruß
Pau

[Torsten Grundke]

Hallo Paul,

nachträglich geht das nicht. Da hilft nur die Datenbank neu anzulegen. Alternativ müßte man bei alle Tabellenspalten den Character-Set ändern, was wahrscheinlich auch nicht immer funktionieren wird (hängt von den bereits vorhandenen daten ab).

Der einzigste saubere Weg ist halt die Datenbank
neu anlegen und dann die Daten importieren.

Tschau

Torste

[Paul Ottenjann]

Hallo Torsten,

habe eine neu Interbase-DB angelegt:
CREATE DATABASE "c:\Programme\PgsDoc\PGSDOC.GDB" USER "PGS" PASSWORD "doc" PAGE_SIZE 2048 DEFAULT CHARACTER SET ISO8859_1;
Fehlt da noch etwas?
Die jeweiligen Tabellen habe ich bisher noch nicht per SQL-Job angelegt, da ich das "Datapump" überlassen möchte.
Wenn ich nun über "Datapump" die Daten von ORACLE nach Interbase "pumpe", dann legt "Datapump" alle Tabellen richtig an - Views legt "Datapump" abenfalls als Tabellen an, kann man aber später noch per sql-Job korrigieren - aber leider schafft "Datapump" es nicht, die Daten vollständig zu kopieren. Es werden alle Tabellen angelegt, pro Tabelle jedoch nur einige Datensätze kopiert und das war's dann.
In der "alten" Interbase-DB - die vor Jahren angelegt wurde - jedoch noch ohne "Character Set" - habe ich dieses Problem nicht. Ich habe auch schon versucht zwischen den beiden Interbase-DB's die Daten per "Datapump" zu kopieren. Verhält sich jedoch wie unter Oracle.
Was könnte das für ein Problem sein?

Schon mal herzlichen Dank für eine weitere Hilfe.

Gruß
Pau

[Torsten Grundke]

Hallo Paul,

das "umschaufeln" zwischen den IB-Datenbanken muß aufgrund der nicht miteinander kompatiblen Character-Set's mit einem kleinen Konvertierungsprogramm erfolgen (d.h. Die Datensätze aus der alten DB einzeln auslesen und in die neue DB einfügen.

Tschau

Torste

[Paul Ottenjann]

Hallo Thorsten,

vielen Dank für die Info. Gibt es dafür bereits fertige Konvertierungsprogramme oder muß ich mir entsprechende sql-Job's erstellen?

Gruß
Pau

[Torsten Grundke]

Hallo Paul,

versuch mal http://www.clevercomponents.com/home/news.asp .

Tschau

Torste

[Paul Ottenjann]

Hallo Thorsten,

herzlichen Dank für die Info's. Habe unter dem Link die richtigen Tools gefunden. Die Daten sind bereits komplett "umgeschaufelt".

Es bleibt aber noch das Problem mit den Views. Das mit Delphi 4 ausgelieferte "Datapump" - Programm legt bei einer Konvertierung der DB's von ORACLE nach INTERBASE die Views als Tabelle an. Das neue "Interbase DataPump Vers. 3.4" bietet für Views keine Möglichkeit.
Nun habe ich per sql-Job die entsprechenden Views in der Interbase-DB angelegt.
Mit dem SQL-Explorer funktionieren die Views soweit auch alle.
Die Daten werden aktualisiert angezeigt.

Wenn ich nun die Delphi-Anwendung starte, erhalte ich bereits zu Anfang eine Exception der Klasse EDBEngineError - Meldung: "Schreibgeschütztes Feld kann nicht geändert werden".
Wenn ich aus den Views wieder Tabellen anlege, läuft die Anwendung durch. Allerdings funktionieren die Views dann nicht in der Anwendung.
Unter ORACLE hat dieses ohne Probleme funktioniert.
Die Views sind seinerzeit als TTable angelegt worden.
Muß dieses nun nach der Umstellung von ORACLE auf INTERBASE umgestellt werden? Und wenn ja, wo muß ich da ansetzen? TTable durch TQuery ersetzten und das war's?

Für eine weitere Unterstützung wäre ich sehr dankbar.

Gruß
Pau

[Torsten Grundke]

Hallo Paul,

Interbase/Firebird unterstützt nur sehr eingeschränkt "Updateable View's". U.a. müssen die Daten alle aus einer Tabelle stammen.

Zusätzlich muß bei der Definition der View dieses auch als Updatefähig definiert werden (ich habe damit keine praktischen Erfahrungen und das online Handbuch hat kein konkretes Beispiel dafür).

Alternativ kann man die Updatefähigkeit auch über Trigger ermöglichen (habe ich bisher auch noch nie gebraucht).

Normalerweise sind View's in IB/FB readonly.

Tschau

Torste

[Paul Ottenjann]

Hallo Thorsten,

besten Dank bisher für Deine tolle Unterstützung.

Vielleicht kannst Du mir ja noch ein wenig helfen.
Und zwar:
- Wo bzw. wie muß ich die View definieren, damit sie auch updatefähig ist?

- Wie sähe beispielsweise eine Trigger-Lösung aus?
Folgende Problematik liegt vor:

Und zwar soll ein Trigger die Tabelle "PGS_V_NEODAT_ZURUECK" immer dann mit <B>allen</B> Daten aus Tabelle "PGS_NEODAT" versorgen, die in dieser Tabelle in der Spalte "Status" den Wert 'Z' haben, wenn in der Tabelle "PGS_NEODAT" eine Änderung vorgenommen wurde. Vorher soll der gesamte Tabelleninhalt der Tabelle "PGS_V_NEODAT_ZURUECK" gelöscht werden. Beide Tabellen haben identische Spalten (ca. 110, z.B. KLNr, PatNr, exportdat, status ...etc.).

Dieses Problem habe ich auch noch als separaten Diskussionsbeitrag eingebracht. Ich hoffe, das geht in Ordnung.

Für weitere Hilfe schon mal meinen herzlichen Dank.

Gruß Pau

[Torsten Grundke]

Hallo Paul,

ich habe ja schon gesagt, dass ich mit Update-fähigen View's keine Erfahrung habe.

Bisher ist mir auch noch keine Konstellation unter die Augen gekommen, in der ich das hätte gebrauchen können.

Im Normallfall verzichte ich vollständig auf View's. Das hat verschiedene Gründe.

Die Trigger zum Reagieren auf Updates werden direkt in den betroffenen Tabellen definiert.

Tschau

Torsten

PS: ein verkürztes Beispiel habe ich Dir im anderen Thread aufgezeig

[Andreas Kosch]

Hallo,

&gt;Wo bzw. wie muß ich die View definieren, damit sie auch updatefähig ist?

ich habe nur ein altes Beispiel am Lager (noch InterBase 5 + BDE): Im Handbuch <i>InterBase 5.0 Data Definition Guide</i> findet sich dazu auf den Seiten 178-179 das folgende Beispiel (ich habe es nur für den Aufruf aus dem SQL-Explorer heraus modifiziert):
<pre>
/* SQL-Explorer-Script */
/* Anw.-Begrenzer: ^ */
/* Beispiel aus InterBase Data Definition Guide */

CREATE TABLE Table1(
ColA INTEGER NOT NULL,
ColB VARCHAR(20),
CONSTRAINT PK_Table1 PRIMARY KEY(ColA)
)
^

CREATE TABLE Table2(
ColA INTEGER NOT NULL,
ColC VARCHAR(20),
CONSTRAINT PK_Table2 PRIMARY KEY(ColA)
)
^

/* Read-Only-View */
CREATE VIEW TableView AS
SELECT Table1.ColA, Table1.ColB, Table2.ColC
FROM Table1, Table2
WHERE Table1.ColA = Table2.ColA
^

CREATE TRIGGER TableView_Delete FOR TableView BEFORE DELETE AS
BEGIN
DELETE FROM Table1 WHERE ColA = OLD.ColA;
DELETE FROM Table2 WHERE ColA = OLD.ColA;
END
^

CREATE TRIGGER TableView_Update FOR TableView BEFORE UPDATE AS
BEGIN
UPDATE Table1 SET ColA = NEW.ColA;
UPDATE Table2 SET ColC = NEW.ColC WHERE ColA = OLD.ColA;
END
^

CREATE TRIGGER TableView_Insert FOR TableView BEFORE INSERT AS
BEGIN
INSERT INTO Table1 VALUES (NEW.ColA,NEW.ColB);
INSERT INTO Table2 VALUES (NEW.ColA,NEW.ColC);
END
^
</pre&gt