Firebird + IBOConsole: unbekannte Tabelle

[Hansa]

Habe den Text hier gefunden und war so frei, den betreffenden Abschnitt anzuhängen. Quelle sind die offiziellen Firebird-Seiten. Finde ich die Internet-Quelle wieder, dann poste ich sie noch. Das wichtigste direkt hier :

Zitat:

Zitat von Firebird

Before the SQL-92 standard, it was not legal to have object names (identifiers) in a database that duplicated keywords in the language, were case-sensitive or contained spaces. SQL-92 introduced a single new standard to make any of them legal, provided that the identifiers were defined within pairs of double-quote symbols (ASCII 34) and were always referred to using double-quote delimiters.
The purpose of this “gift” was to make it easier to migrate metadata from non-standard RDBMSs to standards-compliant ones. The down-side is that, if you choose to define an identifier in double quotes, its case-sensitivity and the enforced double-quoting will remain mandatory.

Das “gift” könnte man IMHO für diesen Fall 1:1 ins Deutsche übersetzen. :P mandatory heißt übrigend obligatorisch. Der Text im Anhang enthält noch zwei Warnkästen. Der eine geht direkt hier auf diese Frage ein. Im zweiten ist meine Warnung wegen des Admin-Tools auch nachzulesen. In IBExpert gibt es eine CheckBox "always capitalize database names". Die ist standardmäßig angekreuzt und wenn man das nicht ändert, dann wird niemals ein Problem auftauchen in Richtung "quotes". Andere Admin-Tools gehen eventuell davon aus, daß quotes Standard sind und dann tauchen Probleme wie jetzt eben auf.

[Piro]

Hi Leute,

ich habe mir mal das Tool IBexpert gezogen und dann die DB mit Tabelle erzeugt und es funktioniert alles. Keine Ahnung watum das mit IBOConsole nicht ging. Jetzt gehts und das ist die Hauptsache.

Danke euch.

P.S.: IBexpert ist ganz schon mächtig und man kann ne Menge einstellen.

[Hansa]

Aha. Problem soweit gelöst.

Zitat:

Zitat von daywalker299

...und man kann ne Menge einstellen.

Aber nicht einstellen verwechseln mit verstellen ! :mrgreen:

Nur das hier, das kann man nicht so im Raum stehen lassen :

Zitat:

Zitat von mkinzler

...Aber wenn eine Tabelle mal Adressen heißt, muß man sie natürlich immer gequotet ansprechen, egal wie/aus was der Zugriff erfolgt.

Eben nicht ! Ich habe nirgends quotes und brauche mir auch nicht die Mühe zu machen, auf Groß/Kleinschreibung zu achten. Der Dialect 3 spielt da auch mit. Lege ich mit IBExpert eine Tabelle an, dann heißt die z.B. ADRESSEN. Nun will ich im Delphi-Programm die Daten haben und schreibe folgendes :

Delphi-Quellcode:

DataSet.Close;
DataSet.SelectSQL.Text := 'SELECT * FROM ADRESSEn';
DataSet.Open;

Man beachte den gewollten Schreibfehler mit dem kleinen n am Schluß. Sollte das Programm aber nicht aus den Angeln heben können. 8) Ist schnell passiert und irgendein Admin-Tool spielt da überhaupt keine Rolle ! Wieso sollte ich da jetzt gezwungen sein, quotes zu verwenden ? :shock:

Gut, machen wir das eben mal so (wie gesagt Delphi-Programm und nicht irgendein Admin-Tool !) :

Delphi-Quellcode:

DataSet.Close;
DataSet.SelectSQL.Text := 'SELECT * FROM adresseN';
DataSet.Open;

Was soll ich denn da mit den quotes anfangen ? Wozu sollen die was nützen ? Anders wäre folgender Fall zu sehen :

SQL-Code:

CREATE TABLE "ADRESSEn"

Ab da würden meine Delphi-Beispiele ungleiche Ergebnisse liefern. Wahrscheinlich wohl gar nichts. :mrgreen: Aber es steht ja alles sowieso in dem Text drin.

[mkinzler]

Zitat:

Nur das hier, das kann man nicht so im Raum stehen lassen :

mkinzler hat folgendes geschrieben:
...Aber wenn eine Tabelle mal Adressen heißt, muß man sie natürlich immer gequotet ansprechen, egal wie/aus was der Zugriff erfolgt.


Eben nicht !

Eben doch. Wenn die Tabelle einmal case-sensitiv angelegt ist, muß man auf diese auch so zugreifen!

[Hansa]

Dann kläre mich mal bitte auf, wie man eine normale FB-DB dazu bringen kann, daß Fehler kommen in Richtung Groß/Kleinschreibung. Und dann noch einen Grund "quotes" zu benutzen. Wo einem eben nichts anderes mehr übrigbleibt, als tatsächlich so was zu benutzen. Habe mal ein kleines Testprojekt gemacht :

Delphi-Quellcode:

procedure TForm1.FormShow(Sender: TObject);
begin
  DS.Close;
  DS.SelectSQL.Text := 'SELECT * FROM taBLe WHERE bez LIKE UPPER (''%TesT%'')';
  DS.Open;
  while not DS.Eof do begin
    showmessage (DS.FieldByName ('NamE').AsString);
    DS.Next;
  end;
end;

Wie man sieht : keine "quotes". Und ob ich das komplett Groß/Klein schreibe oder gemischt wie im Beispiel : es geht immer.

[mkinzler]

Wir reden an einannder vorbei. Er oder IBObjects) hat die Tabell als 'Adressen' angelegt. Dann muß er es auch so ansprechen.

[Piro]

Hi,

übrigens habe ich es auch mit IBOConsole jetzt hinbekommen. Habe irgendwie etwas falsch eingestellt.

[Hansa]

Also gut. Es liegt im Prinzip tatsächlich am Admin Tool :

Fallstudie. Mit IBExpert durchexerziert. Man sehe sich das mal an :

SQL-Code:

CREATE TABLE TEST (
    NEW_FIELD  INTEGER
);

CREATE TABLE "test" (
    NEW_FIELD  INTEGER
);

1. Fall : Einstellung "always capitalize..." ist angekreutzt.

2. Fall : anders rum.

Das betrifft die "quotes" und zeigt, warum die unnötig sind und lediglich Ärger machen ! Sage ich ja schon die ganze Zeit. :mrgreen: Habe lediglich in IBExpert oben bei NEW_TABLE den Namen auf test abgeändert.

Und man sieht ja schön, was dabei raus kommt. Es gilt eben einfach, "quotes" zu vermeiden. Durch Neuanlegen der Table mit vernünftigem Tool war die Fehlerquelle ja sowieso automatisch auch weg. Ursache : siehe oben. Genauso gut hätte man die "" manuell entfernen können.

[mkinzler]

Zitat:

Das betrifft die "quotes" und zeigt, warum die unnötig sind und lediglich Ärger machen ! Sage ich ja schon die ganze Zeit. Mr. Green Habe lediglich in IBExpert oben bei NEW_TABLE den Namen auf test abgeändert.

Und man sieht ja schön, was dabei raus kommt. Es gilt eben einfach, "quotes" zu vermeiden. Durch Neuanlegen der Table mit vernünftigem Tool war die Fehlerquelle ja sowieso automatisch auch weg. Ursache : siehe oben. Genauso gut hätte man die "" manuell entfernen können.

Die Verwendung von Groß-/kleinschreibung in tabellen/spaltennamen ist ein Feature und kein Bug. Man kann sich darüber Streiten ob es sinnvoll ist, aber man kann es aber nicht pauschal als "Gift" bezeichen oder ein Admin-Tool, daß diese benutzt als nicth vernünftig.