Fehler Table anlegen Primary Index

[stalkingwolf]

Hallo zusammen,

ich habe ein Problem was sich mittlerweile häuft und ich habe keine Ahnung woran es liegt.

Wenn ich on the fly Tabellen in einer Firebirddatenbank anlegen möchte dann erhalte ich die Meldung

Code:

*** IBPP::SQLException ***
Context: Transaction::Commit

SQL Message : -607
This operation is not defined for system tables.

Engine Code    : 335544351
Engine Message :
unsuccessful metadata update
cannot create index MYINDEX

Dumpe ich per gbak -b -g die Datenbank und spiele sie wieder ein, dann funktioniert das erstellen der Tabelle.
Da das Flag -g für das aufräumen des Garbage steht vermute ich das die Datenbank vollmüllt.

Jemand eine Idee woran es liegen könnte?

[Neutral General]

Wie sieht denn dein SQL Code dazu aus?

[stalkingwolf]

das ist eigentlich egal.
Man kann auch einen 2 Zeiler als Beispiel schreiben. Der geht ebenfalls nicht durch.

Code:

CREATE TABLE MYTEST
(
   MYSNR Integer NOT NULL,
   CONSTRAINT MYINDEX PRIMARY KEY (MYSNR)
);

[Neutral General]

Wusste gar nicht dass man das so machen kann aber IBExpert z.B. erstellt erst die Tabelle nur mit den Feldern und fügt danach die Constraints hinzu:

Code:

CREATE TABLE BEISPIEL (
  ID INTEGER NOT NULL,
  FELD VARCHAR(20)
);

ALTER TABLE BEISPIEL ADD CONSTRAINT PK_BEISPIEL PRIMARY KEY (ID);

Versuch es vllt. mal so.

[jobo]

Zitat:

Zitat von stalkingwolf (Beitrag 1324544)

das ist eigentlich egal.
Man kann auch einen 2 Zeiler als Beispiel schreiben. Der geht ebenfalls nicht durch.

Code:

CREATE TABLE MYTEST
(
   MYSNR Integer NOT NULL,
   CONSTRAINT MYINDEX PRIMARY KEY (MYSNR)
);

Sollte eigentlich funktionieren. Ich schätze mal, dass Du einfach bereits Objekte in Deiner DB hast, die genauso heißen. Betrifft hier mglw. 3 Objekt Namen, da er beim Index auf die Nase fliegt, aber wohl den PK Constraint Namen bzw. den Indexnamen für den PK constraint.*
Alternativ vielleicht ein Rechte Problem (sysdba Anmeldung).

Schau also einfach mal nach, was Du da schon rumfliegen hast. Gewohnheitsgemäß nimmt man ja für irgendwelche Testtabellen immer ähnliche Namen, z.B. 'test' ;)

Und Zu dem Statement oben:
Du verwendest leider einen etwas irreführenden Namen für den Constraint. Hinter der Formulierung steckt:
FB-Engine, Lege mir einen Constraint namens MYINDEX an (und erzeuge nebenbei automatisch noch einen (unique-weil Primary Key) Index mit einem Namen, den Du Dir selbst ausdenken musst.)
Ergebnis: Der Constraint nennt sich ..Index und der zugehörige Index nennt sich .. unbekannt, die Engine denkt sich einen aus.

Nicht schlimm, aber kann Ärger geben. Nenn den Constraint lieber Rumpelstilzchen oder highlander(es kann nur einen geben), in jedem Fall besser als "..index"
Du nennst das "Nachname"-feld in der Kundentabelle ja vermutlich auch nicht "Vorname".

Idealerweise benennst Du den tatsächlichen Index auch gleich explizit, dann weißt Du im Zweifel beim Umbenennen, Löschen, Reindizieren, wie das Objekt wirklich benamt ist und musst den Namen nicht aus der Datenbank raussuchen, bevor Du es anpackst.

*Der wirkliche Indexname ist ja nicht angegeben, also vielleicht 4 objektnamen. Ich bin kein FB Spezi, weiß nicht, wie FB die (Index)Namen generiert.

P.S: Bevor Du lange nach den Objektnamen suchst. Versuch einfach mal das gleiche Statement mit komplett absurden Namen auszuführen für Table, Column, Constraint. Und noch mal explizit mit Indexname dazu. Vielleicht gehts, dann ist klar, was los ist.

[stalkingwolf]

nein daran liegt es nicht. Ich hatte oben geschrieben das es nach einem gbak funktioniert.
Das Problem liegt nicht an dem Namen.
Das war auch nur ein Test. Die Tabellen lauten sonst anders und haben einen eindeutigen Namen.

Den Index ausserhalb vom CREATE TABLE aufzurufen bringt auch nichts. Fehlermeldung ist die gleiche.

[hstreicher]

[QUOTE=stalkingwolf;1324541Dumpe ich per gbak -b -g die Datenbank und spiele sie wieder ein, dann funktioniert das erstellen der Tabelle.
Da das Flag -g für das aufräumen des Garbage steht vermute ich das die Datenbank vollmüllt.

Jemand eine Idee woran es liegen könnte?[/QUOTE]

das -g räumt nur die Aktuelle Datenbank auf , es wird aber ohnehin nie Garbage ins Backup geschrieben , so dass es bei einem Restore unnötig ist ,

wie sieht es aus mit den Commits , und ist die Datenbank in Benutzung wenn die Tabellen erzeugt werden

Also so:
Commit
Create Table
Commit
Create Index
Commit


mfg Hannes

[stalkingwolf]

Hallo.

Das ist ebenfalls egal. Ob wir es machen wenn die Datenbank in Benutzung ist oder wenn wir alleine darauf sind, die Meldung ist die gleiche.
Es hilft immer nur der gbak.
Die andere Variante haben wir auch probiert. Tabelle anlegen und commiten funktioniert. Index anlegen und der Fehler erscheint.

Wir arbeiten schon seit ein paar Jahren mit Firebird und hatten das Problem so eigentlich noch nie. Es tritt erst in der letzten Zeit häufiger vor. D.h etwas muss dafür ausschlaggebend sein, aber wir haben keinerlei Ansatz was es sein könnte.