Firebird -->Create table

[der-C]

hallo,

folgendes geht:
CREATE TABLE test (col INTEGER)

folgendes geht nicht:
CREATE TABLE test (col VARCHAR(24))

Fehlermeldung "-607 This Operation is not defined for systemtables"

weis jemand weiter?

[mikhal]

Normalerweise sollte das funktionieren.

Hast du vorher mit

SQL-Code:

DROP TABLE test;

deine Tabelle gelöscht, bevor du die Tabelle neu anlegst? Sowohl der Tabellenname als auch der Spaltenname sind sonst bereits vorhanden...

Grüße
Mikhal

[der-C]

ja, das war jetzt nur ein beispiel

dasselbe Problem tritt auf wenn ich mit ALTER TABLE eine spalte adde
mit INTEGER gehts,
mit VARCHAR legt er eine spalte an die aber fehlerhaft ist (ich kann nichts hinneinschreiben)
und beim disconnecten tritt eine fehler auf und die Spalte wird wieder gelöscht

[kiar]

hallo C

wie greifst du auf firebird zu. das solltest du erst mal erklären.
wir sprechen hier uber eine SQL DB da ist die transaktion eine zwingende vorraussetzung.
frage: wie machst du die Transaktionssteuerung.


raik

[der-C]

ich verwende die Zeos komponenten

und transaktion :gruebel: keine Ahnung

fals es was hilft ich verwende Firebird-Embedded und die "Datenbank" wird nur von einem benutzer verwendet

[kiar]

hast du dir das tut von DOMO SOKRAT durchgelesen . ist hier im forum verfügbar. nutze mal die suche.

raik

[der-C]

ja, bin grade drüber

also ich hab mal bei TransactIsolationLevel tiSerializable eingestellt weils ja eigentlich nur einen benutzer für die datenbank gibt.

immernoch der selbe fehler

bei allen CHAR Datentypen (varchar, char, caracter) funktioniert es nicht

[Robert_G]

@C
Frag's Pferd warum das nicht geht. :gruebel:
Sieht für mich nach einem korrekten DML-Statement aus.

@Raik

Etwas OffTopic

Transaktionen bei DDL? :gruebel:
Was soll das bringen? Es wird in jeder DB, mit der ich je gearbeitet habe, autom. ein Commit für die betreffenden Systemtabellen ausgelöst.
Ein...

SQL-Code:

CREATE TABLE Miep (PK integer not null, SomeField VarChar(55))

... heißt, die Tabelle wird sofort erzeugt.
Es gibt DBs (wie zum Bleistift Oracle), die haben sich dabei so zickig, dass sie dieses Commit sogar für die Host transaktion ausführen :roll: :

SQL-Code:

declare
  NewPK Integer;
begin
  INSERT INTO SomeTable i
    (i.SomeField)
  VALUES
    ('lalelu')
  RETURNING i.PK INTO NewPK;
  
  COMMIT;

  UPDATE SomeTable u
  SET    u.SomeField = 'Hallo'
  WHERE  u.PK = NewPK;

  EXECUTE IMMEDIATE 'CREATE TABLE Miep (PK integer not null, SomeField VarChar(55))';

  ROLLBACK;
end;

Man würde das erwarten:

Code:

PK  SomeField
1   lalelu

Da aber das DDL-Statement ein Commit auslöst steht das drin (Das RollBack is wirkungslos):

Code:

PK   SomeField
1    Hallo

Mangels FB in der Firma kann ich dir jetzt nicht sagen, ob FB zu den "zickigen DDL'lern" gehört oder nicht ;)
Vielleicht ist FB auch so konsistent, dass es in einer Serializable transaction kein DDL gestattet. :)

edit: 5 Mio. Tippfehler
noch ein Edit: Boah, da hatte ich doch tatsächlich DML statt DDL geschrieben :oops:

[kiar]

@robert

Zitat:

ich kann nichts hinneinschreiben

darauf habe ich mich bezogen. vielleicht macht mir die zeitumstellung auch zu schaffen :mrgreen:

letzte woche hatte ich aber auch das problem, das eine procedure nicht das gewünschte ergebnis geliefert hat, bis ich merkte, nach zwei stunden :oops: , das ich den wert den ich abfragte noch nicht commitet hatte.

na ja, ich habe zur zeit andere probleme siehe KT :mrgreen:

raik

[Jens Schumann]

Zitat:

Zitat von der-C

...
CREATE TABLE test (col VARCHAR(24))

Ich verwende z.Z. die Firebird Version 1.5.0.4201 1.5 Release Candidate und die IBOConsole in der Version 1.1.96 von L. Mengoni (läuft prima)

Das oben zitierte Statement wird bei mir fehlerfrei abgearbeitet.