Frage an die Firebird-Experten (FB2.1

[hanspeter]

Hallo,
bei mir crascht im Moment eine Software.
Ich bin noch nicht zum Suchen gekommen.
Kann es sein das bei FB 2.1 das Wort "START" zum Schlüsselwort geworden ist?
Zumindest in den Releacenodes habe ich noch nichts gefunden.
Eine Selectanweisung funktioniert nur noch, wenn ich den Tabellenname Start in Anführungsstriche setze.
Select * from Start ->
SQL error code = -104.
Token unknown - line 1, column 15.

Select * from "Start" geht.
Alle anderen Tabellen lassen sich abfragen.

Das kann eine Arbeit werden, in einer alten Software entweder alle SQL Abfragen den Tabellennamen in Anführungsstriche oder die Tabelle selbst umbenennen.

Gruß Peter

[mkinzler]

Scheint so zu sein. unter FB2.1 kann man auch keine Tabelle mit diesem Namen erzeugen.

[hanspeter]

Zitat:

Zitat von mkinzler

Scheint so zu sein. unter FB2.1 kann man auch keine Tabelle mit diesem Namen erzeugen.

Ich liebe undokumentierte Änderungen.
Die Datenbank wurde durch Backup in 1.5 und Restore unter 2.1 erzeugt.
Das hat funktioniert.
IBExpert zeigt die Tabelle Start an, clicke ich auf Daten, dann kan er sie aber nicht öffnen.
Mache ich eine Metadatenausgabe, dann wird die Create-Anweisung für diese Tabelle erzeugt aber keine Metadaten für Insert
extrahiert.

Gruß Peter

[mkinzler]

Die release Notes beziehen sich wohl auch auf Version 2, da die 2.1 ja noch nicht stable ist.

[hanspeter]

Zitat:

Zitat von mkinzler

Die release Notes beziehen sich wohl auch auf Version 2, da die 2.1 ja noch nicht stable ist.

Ich stelle im Moment die Datenbank um.
Da das Programm erst wieder ab März eingesetzt wird, dachte ich 2.0 gleich zu überspringen.
Zumal ich die 64bit Variante ausprobieren wollte.
Das ganze könnte aber auch ein Bug sein. START als Parameter gibt es als "TRANSACTION START" neu in 2.1.
Da wird mir wohl nichts weiter überrigbleiben, als auf 2.0 oder 1.5 zurückzugehen.

Gruß Peter

[mkinzler]

Oder den Tabellenname zu ändern, wenn du wie ich die hoffnung nicht aufgegeben hast das die Version bis April endlich fertig ist.

[Hansa]

Zitat:

Zitat von hanspeter

..Das ganze könnte aber auch ein Bug sein. START als Parameter gibt es als "TRANSACTION START" neu in 2.1.
Da wird mir wohl nichts weiter überrigbleiben, als auf 2.0 oder 1.5 zurückzugehen...

Erstens ist es immer bedenklich BEGIN, END, PROCEDURE usw. als Identifier zu benutzen (START auch). Da sage ich nur : selber Schuld, Anfängerfehler. :mrgreen:

Da dem aber anscheinend so ist, dann stelle den Namen um. Alles andere ist Blödsinn.

[hanspeter]

Zitat:

Zitat von Hansa

Zitat:

Zitat von hanspeter

..Das ganze könnte aber auch ein Bug sein. START als Parameter gibt es als "TRANSACTION START" neu in 2.1.
Da wird mir wohl nichts weiter überrigbleiben, als auf 2.0 oder 1.5 zurückzugehen...

Erstens ist es immer bedenklich BEGIN, END, PROCEDURE usw. als Identifier zu benutzen (START auch). Da sage ich nur : selber Schuld, Anfängerfehler. :mrgreen:

Da dem aber anscheinend so ist, dann stelle den Namen um. Alles andere ist Blödsinn.

Wieso Anfängerfehler?
Die Tabelle mit diesem Namen gibt es seit 1987 und hat alle Neu- und Weiterentwicklungen bis heute überlebt.
Mit dem Umstellen des Tabellennamens ist es nicht getan, da eine Reihe Trigger und Stored Procedure dranhängen.
1.2 Mio Quellzeilen nach Bezügen auf diese Tabelle abzusuchen ist auch nicht trivial.
Da ist zurück auf 2.0 bzw. 1.5 der einfachere Weg. 2.1 und größer bringt in einem bestehenden Projekt ohnehin nicht viel.
Und im übrigen in der Liste der reservierten Worte, sowie der evenduell zukünftig reservierten Worte ist dieser Begriff nicht.
Mir ist der Fehler nur untergekommen, da ein Anwender über Weihnachten versuchsweise FB2.1 installiert hatte.

p.s. warum bist du eigentlich so agressiv?

Peter

[Hansa]

Hanspeter, warst du 1987 an dem Design der DB beteiligt, oder wie ? Gabs damals schon Interbase ? :shock: Aber egal, Allerweltswörter scheiden als Identifier grundsätzlich aus. Wie man sieht : selbst nach 20 Jahren kann sich das rächen. Um nun solchem Ungemach aus dem Weg zu gehen, gibt es einen einfachen Weg : deutsche Identifier benutzen, dann passiert sehr wahrscheinlich überhaupt kein Fehler in dieser Art. "Start" ist zwar auch deutsch, aber was wäre mit "Anfang" gewesen ? Wohl kein Problem. Nur als Tip.

Zitat:

Zitat von hanspeter

...da ein Anwender über Weihnachten versuchsweise FB2.1 installiert hatte.

..dann sei doch foh, dass der Fehler früh genug aufgefallen ist und stelle die DB frühzeitig (also jetzt) um.

[hanspeter]

Zitat:

Zitat von Hansa

Hanspeter, warst du 1987 an dem Design der DB beteiligt, oder wie ? Gabs damals schon Interbase ? :shock: Aber egal, Allerweltswörter scheiden als Identifier grundsätzlich aus. Wie man sieht : selbst nach 20 Jahren kann sich das rächen. Um nun solchem Ungemach aus dem Weg zu gehen, gibt es einen einfachen Weg : deutsche Identifier benutzen, dann passiert sehr wahrscheinlich überhaupt kein Fehler in dieser Art. "Start" ist zwar auch deutsch, aber was wäre mit "Anfang" gewesen ? Wohl kein Problem. Nur als Tip.

Zitat:

Zitat von hanspeter

...da ein Anwender über Weihnachten versuchsweise FB2.1 installiert hatte.

..dann sei doch foh, dass der Fehler früh genug aufgefallen ist und stelle die DB frühzeitig (also jetzt) um.

Lassen wir das, die Diskussion hat ehe keinen Sinn.
Ja ich habe die Datenbank 1987 entworfen. Sie setzte in Turbopascal auf dem typisierten Files auf und wurde später auf Dbase III umgestellt.
Interbase kam ins Spiel als dieses Opensource wurde. Die Daten wurden immer über Software konvertiert.
Und "Anfang" für eine Datei, welche Starter und Startlisten enthält?
Ich denke das dies ein Parserfehler ist, welcher in der kommenden Version erledigt sein wird.


Gruß Peter

[Ralf Kaiser]

Zitat:

Zitat von Hansa

deutsche Identifier benutzen, dann passiert sehr wahrscheinlich überhaupt kein Fehler in dieser Art.

Oder ein anderer Tipp: Prefixe für verschiedene Typen von Datenbankobjekten:

Tabelle: tabStart
Stored Procedure: procStart
Trigger: trigStart
View: viewStart

usw.

So kann man englische Namen verwenden, vermeidet Kollisionen mit reservierten Worten und erkennt sofort um was für ein Objekt es sich handelt.

(Ja, ja ich weiss: hinterher ist es immer leicht solche Vorschläge zu machen)

Ciao,
Ralf

[hanspeter]

Zitat:

Zitat von Alfi001

Zitat:

Zitat von Hansa

deutsche Identifier benutzen, dann passiert sehr wahrscheinlich überhaupt kein Fehler in dieser Art.

Oder ein anderer Tipp: Prefixe für verschiedene Typen von Datenbankobjekten:
chen)

Ciao,
Ralf

Diese Methode verwende ich seit mehreren Jahren bei neuen Programmen konsequent.
Diverse Entwurfstools unterstützen das fast automatisch von Haus aus.
Das Programm ist eine auf Delphi portierte Altlast und echt hausgebacken.
Ich freunde mich immer mehr mit der Idee an, eine grundsätzliche Revision verbunden mit einer Portierung auf .Net und C#
durchzuführen. Scheue aber noch etwas den Aufwand und warte auf einen etwas umgänglicheren WPF.
Übrigens gibt es wohl in FB noch mehr Probleme bei Namen, welche mit Start anfangen.
So führt z.B. ein Bezeichner "STARTS" ebenfalls zum Fehler.

Gruß Peter

[Thanatos81]

Versuch doch mal in deinen Abfragen und Prozeduren START durch "START" zu ersetzen, das hat bei mir mal geholfen, als ich eine Fremd-DB mit Bezeichnern hatte, bei denen Groß-/Kleinschreibung zu beachten war.

[hanspeter]

Zitat:

Zitat von Thanatos81

Versuch doch mal in deinen Abfragen und Prozeduren START durch "START" zu ersetzen, das hat bei mir mal geholfen, als ich eine Fremd-DB mit Bezeichnern hatte, bei denen Groß-/Kleinschreibung zu beachten war.

Natürlich geht das.
Gegen diese Lösung sprechen eher praktische Gründe.
Der User kann selbst SQL Anweisungen eingeben. Wie bringe ich diesem bei, genau eine Tabelle mit Anführungszeichen zu schreiben?
Und was wesentlich schwerer wiegt IBexpert kommt mit diesen Tabellenbezeichnern nicht klar.
Ich kann die Tabelle in IBexpert weder öffnen, noch funktioniert ein Metadatenimport/Export.
Backup geht, Restore führt ebenfalls zum Fehler.


Gruß Peter

[hoika]

Hallo,

START wird von anderen DB's anstelle von STARTING verwendet.

Ich hätte noch den Vorschlag, die Tabelle Start in Start2 umzubenennen
und einen View Start zu erzeugen.
den kann man ja "leicht" read-write machen (über SP's).


Heiko
PS: Firebird2 nähert sich SQL2003, deshalb klappt es unter der 1.5 noch.

[TBx]

Zitat:

Zitat von hanspeter

Und was wesentlich schwerer wiegt IBexpert kommt mit diesen Tabellenbezeichnern nicht klar.

Das ist ja auch kein Wunder, da der IBExpert nur diejenigen reservierten Schlüsselworte automatisch in Anführungszeichen setzen kann, die er auch als solche kennt.
Das funktioniert in dem Prog sonst nämlich automatisch, ich habe in einer Kundendatenbank mal eine Tabelle Namens LOCK gefunden, die konnte er problemlos bearbeiten.
Da Du Dein Problem ja auch in der IBExpert-Newsgroup gepostet hast, wird sich der Problematik sicher angenommen werden.

Gruß

onlinekater