Fehler in SQL-Syntax

[bra]

Darum am besten am Ende oder Anfang jeder Zeile ein Leerzeichen einfügen.

[nahpets]

Um solchen Fehlern aus dem Weg zu gehen, nehme ich da immer Stringlisten. Der zusätzliche Schreibaufwand ist deutlich geringer als die Zeit, die man zur Fehlersuche benötigt.

Delphi-Quellcode:

function TDMLSQLite.CreateTblHtml :String; // "ContentMasterData". ContentMasterData.
  var SQLString: TStringList;
begin
  SQLString := TStringList.Create; 
  SQLString.Add('CREATE TABLE tbl_Html(');
  SQLString.Add('  idHtml INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,');
  SQLString.Add('  MenueCSS INTEGER NOT NULL CHECK(MenueCSS>=0),');
  SQLString.Add('  PageCSS INTEGER NOT NULL CHECK(PageCSS>=0),');
  SQLString.Add('  MenueID INTEGER NOT NULL CHECK(MenueID>=0),');
  SQLString.Add('  HTMLPage LONGTEXT NOT NULL,');
  SQLString.Add('  URL VARCHAR(45) NOT NULL,');
  SQLString.Add('  tbl_Javascript_idJavascript INTEGER NOT NULL,');
  SQLString.Add('  tbl_CSS_idCSS INTEGER NOT NULL CHECK(tbl_CSS_idCSS>=0),');
  SQLString.Add('  tblgalerie_Gallery_ID INTEGER NOT NULL CHECK(tblgalerie_Gallery_ID>=0),');
  SQLString.Add('CONSTRAINT fk_tbl_Html_tbl_Javascript1');
  SQLString.Add('  FOREIGN KEY(tbl_Javascript_idJavascript)');
  SQLString.Add('  REFERENCES tbl_Javascript(idJavascript),');
  SQLString.Add('CONSTRAINT fk_tbl_Html_tbl_CSS1');
  SQLString.Add('  FOREIGN KEY(tbl_CSS_idCSS)');
  SQLString.Add('  REFERENCES tbl_CSS(idCSS),');
  SQLString.Add('CONSTRAINT fk_tbl_Html_tblgalerie1');
  SQLString.Add('  FOREIGN KEY(tblgalerie_Gallery_ID)');
  SQLString.Add('  REFERENCES tblgalerie(Gallery_ID))';
  Result := SQLString.Text;
  SQLString.Free;
end;

Und schlechter zu lesen ist es auch nicht.

[Delbor]

Hi zusammen

Vielen Dank an euch alle!! Ich hätte das noch öfters übersehen, trotz Vergleichen mit dem Original-Export!

Delphi-Quellcode:

'tbl_CSS_idCSS INTEGER NOT NULL CHECK(tbl_CSS_idCSS>=0),'+
'tblgalerie_Gallery_ID INTEGER NOT NULL CHECK(tblgalerie_Gallery_ID>=0),'+
'CONSTRAINT fk_tbl_Html_tbl_Javascript1'+
  'FOREIGN KEY(tbl_Javascript_idJavascript)'+
  'REFERENCES tbl_Javascript(idJavascript),'+
'CONSTRAINT fk_tbl_Html_tbl_CSS1'+
  'FOREIGN KEY(tbl_CSS_idCSS)'+
  'REFERENCES tbl_CSS(idCSS),'+

Nach euren Rückmeldungen fällt mir jetzt auf: Die Zeilen oberhalb der Constraintsangaben enden alle mit ",'+", haben also auch keine Leerzeichen - dafür mit dem Komma aber ein Trennzeichen, so dass der Compiler nicht "an der Nase herumgeführt" werden kann.

Zu Nahpeds Vorschlag mit der Stringliste: Mal sehen, ob ich mir das angewöhnen kann...

Nachtrag:

Zitat:

Der zusätzliche Schreibaufwand ist deutlich geringer als die Zeit, die man zur Fehlersuche benötigt.

Gerade bei solch importierten Scripten schauert mich eigentlich der Gedanke etwas, für jedes einzelne Statement einen Funktionskopf zu schreiben - und zu wohl 80 - 90% immer dasselbe eintippen zu müssen.
Meine Lösung dafür: Eine Quelltextvorlage. Die kan dann auch gleich das Handling mit der Stringliste enthalten. Der Rest ist Copy&Paste und Drag&Drop...

Gruss
Delbor

[Uwe Raabe]

Solche SQL Skripte editiere ich gerne in einer separaten Textdatei mit Extension SQL. Da bekomme ich in der IDE nämlich auch gleich eine entsprechende Syntaxhervorhebung. Passt dann alles, wird der Text über Copy und MultiPaste (im Menü Bearbeiten - Mehrfach einfügen) mit dem entsprechenden Prefix/Postfix versehen eingefügt. Dann muss lediglich noch am Ende etwas korrigiert werden.

[haentschman]

Moin...
[OT]
Du bist der richtige Kandidat für SQL States in Ressourcen. Da fallen ALLE "SQL.Add" bzw. "+" einfach weg.
http://www.delphipraxis.net/49505-sq...einbinden.html

[Achtung Schleichwerbung]
Mit meinem SQL Resource Creator kannst du auch das Statement direkt testen...
Statt:

Zitat:

Solche SQL Skripte editiere ich gerne in einer separaten Textdatei mit Extension SQL.

...@Uwe: sorry.

http://www.delphipraxis.net/190316-d...e-creator.html
[/OT]

[Uwe Raabe]

Zitat von haentschman:

...@Uwe: sorry.

Kein Problem! Kann ja jeder selbst entscheiden, ob er seine SQL-Statements als String-Konstante oder String-Resource haben will.

[nahpets]

Gehen wir mit Uwes Vorschlag noch etwas weiter und ignorieren den von haentschman:

Die Scripte werden als Dateien gespeichert und zur Laufzeit geladen. Hat den Vorteil, man muss bei Scriptänderungen nicht auch das Programm ändern. Man lädt einfach nur die Scripte und gut ist:

Delphi-Quellcode:

function TDMLSQLite.CreateTblHtml :String; // "ContentMasterData". ContentMasterData.
  var SQLString: TStringList;
begin
  SQLString := TStringList.Create;
  SQLString.LoadFromFile('TblHtml.sql'); 
  Result := SQLString.Text;
  SQLString.Free;

Wenn man's noch weiter vereinfacht, dann übergibt man den Namen des Scriptes als Parameter und muss nicht mehr für jede Tabelle ... eine eigene Funktion erstellen.

SQL-Code:

-- Erstellscript für die Tabelle tbl_html
-- Scriptedate: tbl_html.sql
CREATE TABLE tbl_Html(
  idHtml INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
  MenueCSS INTEGER NOT NULL CHECK(MenueCSS>=0),
  PageCSS INTEGER NOT NULL CHECK(PageCSS>=0),
  MenueID INTEGER NOT NULL CHECK(MenueID>=0),
  HTMLPage LONGTEXT NOT NULL,
  URL VARCHAR(45) NOT NULL,
  tbl_Javascript_idJavascript INTEGER NOT NULL,
  tbl_CSS_idCSS INTEGER NOT NULL CHECK(tbl_CSS_idCSS>=0),
  tblgalerie_Gallery_ID INTEGER NOT NULL CHECK(tblgalerie_Gallery_ID>=0),
  CONSTRAINT fk_tbl_Html_tbl_Javascript1
    FOREIGN KEY(tbl_Javascript_idJavascript)
    REFERENCES tbl_Javascript(idJavascript),
  CONSTRAINT fk_tbl_Html_tbl_CSS1
    FOREIGN KEY(tbl_CSS_idCSS)
    REFERENCES tbl_CSS(idCSS)
  CONSTRAINT fk_tbl_Html_tblgalerie1
    FOREIGN KEY(tblgalerie_Gallery_ID)
    REFERENCES tblgalerie(Gallery_ID)
);

Delphi-Quellcode:

function TDMLSQLite.CreateTbl(AScriptName : String) :String;
  var SQLString: TStringList;
begin
  if FileExists(AScriptName) then begin
    SQLString := TStringList.Create;
    SQLString.LoadFromFile(AScriptName); 
    Result    := SQLString.Text;
    SQLString.Free;
  end else begin
    MessageDlg(Format('Script nicht gefunden: %s',[AScriptName]),mtError,[mbOK],0);
  end;
end;

Vorteil:
Funktionierende Scripte kann man nicht mehr versehentlich "verunstalten".
Scriptänderungen haben keine direkte Auswirkung auf das Kompilat des Programmes.

[Delbor]

Hi Uwe Raabe

Ich hatte die Datei (*.sql) mit Notepad++ geladen. Der hat auch Syntaxhighliting, auch für diverse Dateiendungen. Ausgereizt habe ich dessen Möglichkeiten allerdings noch nicht wirklich.
Aber auch so ist er nützlich, kann er doch das eine oder andere, das Texteditoren normalerweise nicht können.

Gruss
Delbor

PS: Die neunen Beiträge habe ich soeben gesehen, möchte aber gesondert darauf eingehen

[haentschman]

Moin...
Einspruch euer Ehren...

Zitat:

Die Scripte werden als Dateien gespeichert und zur Laufzeit geladen. Hat den Vorteil, man muss bei Scriptänderungen nicht auch das Programm ändern. Man lädt einfach nur die Scripte und gut ist:

Das öffnet der SQL Injection Tor und alle Türen.
https://de.wikipedia.org/wiki/SQL-Injection

Die SQL sollten nie vom User änderbar sein.

PS:

Zitat:

ignorieren den von haentschman:

...sagt mein Arzt auch immer. "Alle ingnorieren mich! Der nächste bitte."

Zitat:

Hat den Vorteil, man muss bei Scriptänderungen nicht auch das Programm ändern.

Aber auch den Nachteil, unabhängig von der Injection, daß der User das Programm ins Code Nirvana schicken kann.

[Uwe Raabe]

Zitat von haentschman:

Das öffnet der SQL Injection Tor und alle Türen.

Ist zwar bei Resourcen nicht ganz so einfach, aber auch möglich: http://www.angusj.com/resourcehacker/