Welchen Fehler hab ich im SQL Statement??

[winx]

Hallo,

wenn ich folgende Abfrage an meine Access DB richte bekomme ich immer eine Exception:

Delphi-Quellcode:

    sqlStatement :=  'SELECT EAN-ABAS FROM Typenschilder WHERE Typenschilder.MaskeT = "NT"';
    ADOQuery.SQL.Clear;
    ADOQuery.SQL.Text := sqlStatement;
    Logger.Debug('SQL QUERY: '+sqlStatement);
    ADOQuery.Open;   
    Repeat
      Logger.Debug(ADOQuery.FieldByName('EAN-ABAS').AsString); //FEHLER
      ADOQuery.Next;
    until ADOQuery.EOF;

Wenn ich jedoch eine Spalte ohne "-" abfrage kommt was zurück

Delphi-Quellcode:

    sqlStatement :=  'SELECT Typennummer FROM Typenschilder WHERE Typenschilder.MaskeT = "NT"';
    ADOQuery.SQL.Clear;
    ADOQuery.SQL.Text := sqlStatement;
    Logger.Debug('SQL QUERY: '+sqlStatement);
    ADOQuery.Open;
    Repeat
      Logger.Debug(ADOQuery.FieldByName('Typennummer').AsString);
      ADOQuery.Next;
    until ADOQuery.EOF;

Wie muß ich die Anfrage stellen damit es läuft???

Gibt es irgendwo n Beispiel???

Danke,
winx

[Loki77]

- wird hier halt als operator genommen, kann die gerade aber auch nicht sagen wie man das löst...
Hab in dem Fall immer Felder mit _ geschrieben...
Hatte mal das problem mit Feldname "PLZ/Ort", "PLZ_Ort" klappt dann.

[joachimd]

Zitat:

Zitat von winx

'SELECT EAN-ABAS FROM Typenschilder WHERE Typenschilder.MaskeT = "NT"'

Du gibst im SQL vor, dass eine Differenz der beiden Felder EAN und ABAS gewünscht ist. Wenn Sonderzeichen im Bezeichnernamen vorkommen, musst Du den Bezeichner quoten. SQL Standard ist [komischer Name], µ$ SQL und manche andere verstehen auch "komischer Name".

[Schrammel]

Ich glaube, es muss heißen:

Delphi-Quellcode:

sqlStatement :=  'SELECT EAN-ABAS FROM Typenschilder WHERE Typenschilder.MaskeT = "NT"';

Probiers mal damit!

Gruss

Stefan

[Schrammel]

Das war jetzt ganz schlau von mir, ich habe vergessen, das Statement zu korrigieren. Also nochmal:

Ich glaube, es muss heißen:

Delphi-Quellcode:

sqlStatement :=  'SELECT [EAN-ABAS] FROM Typenschilder WHERE Typenschilder.MaskeT = "NT"';

Probiers mal damit!

Gruß

Stefan

[shmia]

Wer einen Feld- oder Tabellennamen mit einem Minuszeichen wählt,
dem sollte man gleich einen Dübel bohren. :twisted:
Du würdest ja auch nie auf die Idee kommen, Variablen dieser Art in Pascal zu deklarieren:

Delphi-Quellcode:

var
   EAN-Nummer : integer;
   2fach : boolean;

[Loki77]

Zitat:

Wer einen Feld- oder Tabellennamen mit einem Minuszeichen wählt,
dem sollte man gleich einen Dübel bohren.

Einmal den Fehler gemacht, immer dran gedacht!
(sch...limmer Spruch)

[winx]

Das mit [] funktioniert :-)

Leider hab ich nich die DB erstellt, sondern darf sie nur verwenden :wall:

[Schrammel]

Da sieht man mal wieder, dass Tips der Kategorie "Aus der Praxis für die Praxis" auch noch ihre Daseinsberechtigung haben neben konzeptionellen Wolkenschieberein der Kategorie "... sowas darf man doch nicht machen, das geht an allen Standards vorbei...".

Lasst uns lernen, mit den Fehlern unserer Vorgänger zu leben und das Beste daraus zu machen!

MfG

Stefan

[shmia]

Zitat:

Zitat von Schrammel

Da sieht man mal wieder, dass Tips der Kategorie "Aus der Praxis für die Praxis" auch noch ihre Daseinsberechtigung haben neben konzeptionellen Wolkenschieberein der Kategorie "... sowas darf man doch nicht machen, das geht an allen Standards vorbei...".
Lasst uns lernen, mit den Fehlern unserer Vorgänger zu leben und das Beste daraus zu machen!

Drei Jahre später...
Die Datenbank und die Anwendung erfreuen sich beim Endkunden grosser Beliebtheit.
Nun ist allerdings die Access-Datenbank nicht mehr ausreichend, es wird auf Oracle umgestiegen.
Schade, nun läuft aber diese eine Abfrage mit den eckigen Klammer nicht mehr, da bei Oracle hier Anführungszeichen verwendet werden müssten.
Leider hat der ursprüngliche Programmierer die Firma verlassen.
Der Kunde ist sauer und verlangt sofortige Behebung des Fehler.
Ein einziges Minuszeichen führt also zu bösen Briefen an die Geschäftsleitung, sowie Aufwand ohne Bezahlung.
:warn: Man kann also nur davor warnen, Feld- oder Tabellennamen falsch zu wählen; es sind tickende Zeitbomben

[Schrammel]

@shmia:

Ich stimme dir ja zu, dass man das in einer neu anzulegenden Datenbank nicht macht!

Aber hier haben wir anscheinend bereits den Fall, dass eine Datenbank vorhanden ist, die verwendet werden muss. Da lohnt es sich nicht, sich Gedanken über das "Hätte man und "Sollte man" oder das "Hätte man besser nicht" oder "sollte man besser nicht" zu machen.

Hier kommt es darauf an, das konkrete Problem zu lösen.

Ich stimme Dir auch zu, dass man so einen Zustand schafft, der zu einem späteren Zeitpunkt X zum Problem werden kann. Wenn ich das jedoch gegen das jetzige Problem abwäge, so kann ich als Außenstehender keinen qualitativen Unterschied erkennen, was die Maßnahme meiner Ansicht nach grundsätzlich rechtfertigt.

winx hat ja anscheinend nicht den Auftrag, eine Datenbank grundsätzlich auf neue solide füße zu stellen, sondern ein spezielles Problem zu lösen. Wenn dieses Problem ausreichend übersichtlich ist, wird der Kunde sich lieber eine Hand abhacken, als einem kostenintensiven Gesamt-Refactoring der Datenbank zuzustimmen.

Um das Wissen über den ergriffenen Workaround nicht verlorengehen zu lassen bietet sich die Nutzung von ALM-Produkten an. Wer weiß, vielleicht finden wir zwei beide einen Link auf diesen Thread im Konfigurations-Management-System unseres nächsten Arbeitgebers wieder! :)


MfG

Stefan