Search the FirstSpirit Knowledge Base
Hallo,
mich würde mal das Standardverhalten interessieren, wenn man ein Datenschema aus einer Derby DB in einen Oracle Layer importiert. Und bitte jetzt nicht sagen: "das macht man nicht" - das wissen wir auch . Lässt sich aber leider in diesem Fall nicht vermeiden. Ich möchte gerne wissen, wie man das am besten handhaben kann, ohne Datenverlust.
Erst einmal, sind folgende Annahmen richtig?
Soweit so gut, meine Beoabachtung ist aber nun, dass durch diese Kürzung Mehrdeutigkeiten entstehen können, die offenbar von FS nicht aufgelöst werden. Meine zweite Beobachtung ist, dass nicht alle Namen auf 30 Zeichen gekürzt werden, sondern teilweise auf 32.
1. Beobachtung
Lege ich im Schema z.B. "Eine_tolle_Tabelle_mit_mehr_als_30_Zeichen" an, wird der dbName artig auf 30 Zeichen gekürzt: dbName="EINE_TOLLE_TABELLE_MIT_MEHR_AL"
Dann lege ich eine weitere Tabelle an, wobei die ersten 30 Zeichen identisch sind: "Eine_tolle_Tabelle_mit_mehr_als_30_Zeichen_im_Namen", wird hier nicht gekürzt, sondern es kommt beim Speichern die folgende Fehlermeldung:
Fehler beim Datenbankzugriff:
java.sql.SQLException: ORA-00972: Bezeichner ist zu lang
FSVersion=4.2.461.48921#2372;JDK=1.6.0_32 32bit Sun Microsystems Inc.;OS=Windows XP 5.1 x86;Date=26.06.2012 14:33:13
de.espirit.or.SchemaException: java.sql.SQLException: ORA-00972: Bezeichner ist zu lang
at de.espirit.or.impl.generic.GenericTableSynchronizer.updateDB(GenericTableSynchronizer.java:171)
...usw.
Hier muss man also offenbar genau aufpassen, was man tut, um Mehrdeutigkeiten zu vermeiden...
2. Beobachtung
Gibt es keine o.g. Mehrdeutigkeiten, lässt sich das Schema zunächst speichern und alles scheint in Ordnung. Aber beim nächsten Bearbeiten kann es evtl. zu der folgenden Fehlermeldung kommen:
FSVersion=4.2.446.45868#2463;JDK=1.6.0_31 32bit Sun Microsystems Inc.;OS=Windows 7 6.1 x86;Date=21.06.2012 14:56:37
de.espirit.or.SchemaException: de.espirit.or.SchemaException: java.sql.SQLException: ORA-00955: name is already used by an existing object
...
Hier haben wir herausgefunden, dass zwar die Namen der eigentlichen Tabellen richtig gekürzt werden, z.B.
<xs:complexType dbName="EINE_TOLLE_TABELLE_MIT_MEHR_AL" name="Eine_tolle_Tabelle_mit_mehr_als_30_Zeichen">
die Index Namen hingegen werden auf 32 statt 30 Zeichen gekappt:
<xs:key dbName="PK_EINE_TOLLE_TABELLE_MIT_MEHR_0" name="pk_Eine_tolle_Tabelle_mit_mehr_als_30_Zeichen">
Warum das genau passiert, habe ich noch nicht ganz begriffen. Ist das ein Bug oder liege ich generell falsch damit, dass FirstSpirit diese Kürzungen vornimmt und es ist am Ende gar nicht vorgesehen, dass man überhaupt aus Derby in Oracle importieren kann?
Ich weiß, das waren jetzt mehrere Dinge gleichzeitig, aber gibt es zu dem Thema eine Aussage, bzw. wie wird das Verhalten in 5.0 sein? Ist das alles ein alter Hut oder hat es nur bislang keiner gemerkt.
Grüße
Matthias
Hallo Matthias,
ich bezweile, dass schon jemand in solche Probleme gelaufen ist. Das Problem ist schon speziell und es müssen einige Faktoren zusammen kommen:
An der Einschränkung von Oracle kann FirstSpirit auch nichts drehen und wie weit die Intelligenz von FirstSpirit in solchen Fällen gehen muss ist fraglich. Du kannst an unseren Helpdesk mal das Projekt schicken (am besten nur den wesentlichen Teil, sofern es größer ist) und genauere Informationen in welche Oracle-Version das importiert wurde etc. Aber ich kann dir nicht versprechen, dass das als Bug eingestuft wird.
Der praktische und schnelle Rat wäre das Datenmodell in Oracle neu zu modellieren. Die Daten aus der Derby zu exportieren (als SQL-Statements oder CSV), in der Datei die Tabellennamen zu patchen und diese dann in die Oracle zu importieren.
Hallo Christoph,
vielen Dank für die schnelle Antwort. Ich kann nicht glauben, dass ich nach über 12 Jahren Produktgeschichte der erste bin, dem das auffällt. Aber da ich ja nach dem Standardverhalten von FS in so einer Situation gefragt habe, ist meine Frage damit beantwortet. Offenbar ist dieser Fall nicht vorgesehen und wird auch nicht abgefangen. Damit ist unser Fix, nämlich manuelle Nachbearbeitung des XML, schon die Lösung und zukünftige Erweiterungen des Schemas machen wir nur noch auf Oracle, dann sollten wir einigermaßen sicher sein.
Hallo Matthias,
ich habe jetzt nicht alle Tickets durchforscht, ob schon mal jemand ein ähnliches Problem hatte, aber wie gesagt, es kommen ja schon einige Bedinungen zusammen. Die Idee das XML im Export zu patchen sollte eigentlich auch funktionieren und auch weniger Aufwand bedeuten.
Viele Grüße
Christoph