Fehler in SQL-Syntax

[Uwe Raabe]

Zitat:

Zitat von haentschman (Beitrag 1381599)

...@Uwe: sorry. :wink:

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...:P
Einspruch euer Ehren... :warn:

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. :shock:
https://de.wikipedia.org/wiki/SQL-Injection

Die SQL sollten nie vom User änderbar sein. :roll:

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:

Zitat von haentschman (Beitrag 1381603)

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

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

[Delbor]

Hi zusammen

Approppo Scripte und Dateien: Ich hab in den letzten Tagen ziemlich auf Embarcaderos Seiten geblättert und dabei TFDScripts, bzw. TFDScript entdeckt. Auch da können Statments aus Dateien geladen werden.
Allerdings habe ich damit noch ein Problem:
Meine Insert-Funktionen laufen in einer bestimmten Reihenfolge ab, und jede ermittelt am Ende den zuletzt eingefügten PK (last_insert_id bei MySQL) und gibt den für den FK an die nächste Funktion weiter.
Unter Verwendung von TFDScripts ruft ja das Root-Element die diversen Statements auf. Bisher habe ich noch keine Möglichkeit gefunden, dass das eine aufgerufene Script einen Integer (Last-RowID bzw. LastInsertID) an TFDScripts zurückgeben kann.
Was habe ich übersehen oder überlesen?

Zitat:

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

Hmm..Ja! Und wenn man die Dinger in eine Art Cab-Datei packt?

OK, dann müssten die erstmal entpackt werden. Und der User könnte so eine Datei auch unbeabsichtigt ins Nirwana schicken..

Gruss
Delbor

[hsg]

Alternative zur Speicherung in Dateien: Speicherung in einer Datenbank-Tabelle :-D
So mache ich es inzwischen bei einer Applikation. Dabei sind die Statements noch zusätzlich aufgeteilt in "Select", "Join", "Where" und "Order"-Abschnitt. Bei Bedarf kann so das verwendete Statement noch entsprechend vom Programm (z.B. durch Angabe von zusätzlichen Where-Bedingungen, Joins oder Sortierreihenfolgen) angepasst werden.
Zwei kleine Funktionen liefern mir dann das passende Skript an die benötigte Stelle.

Normale Benutzer kommen so an die Statements nicht heran, reduziert also deutlich die Gefahr der Injection.

[nahpets]

Ob Datei, Resource, Datenbank oder direkt im Programmcode:

Kommt auf die Aufgabe an.

Software für Normalverbraucher und spielwütige: Alles im Programmcode.

Resource, wenn man in bedingtem Umfang datenbankunabhängig sein will.
Es wird die entsprechende Resource eingebunden. SQL ist ja leider nicht gleich SQL, die Unterschiede bei den Dialekten können schon recht gravierend sein.

Datenbank: Das hat was, mache ich auch meist so. Anpassungen sind jederzeit möglich. Aber es wird ein entsprechendes Berechtigungssystem benötigt, damit nicht jeder da "rumwuseln" kann, sondern nur die, die dazu autorisiert sind. Im professionellen Umfeld also eher ein Datenbankadmin.

Datei ist eigentlich ähnlich zur Datenbank zu sehen: Nicht jeder darf, sondern nur autorisierte. Ansonsten sind die Scripte so abgelegt, dass sie nicht allgemein zugänglich sind. Das dürfte in jeder vernünftigen, professionellen Umgebung gegeben sein.

ZIP ...: Die kann man passwortgeschützt erstellen, da kann dann auch so schnell keiner mal eben was dran ändern. Auch darüber kann man dann Scripte datenbankunabhängig zur Verfügung stellen. Je Datenbanktyp eine ZIP mit den passenden Scripten. Ausgeliefert wird die, die zur Datenbank des Kunden passt.

Keine der Möglichkeiten ist grundsätzlich besser als die anderen und keine ist grundsätzlich abzulehnen. Es kommt halt auf die konkret zu erstellende Software und die Umgebung, in der sie zum Einsatz kommen wird, an.

[Delbor]

Hi zusammen
Neueste Fehlermeldung:

Zitat:

---------------------------
Im Projekt SQLiteTestProject.exe ist eine Exception der Klasse ESQLiteNativeException mit der Meldung '[FireDAC][Phys][SQLite] ERROR: unknown database tbl_Html' aufgetreten.
---------------------------

Die bisher debattierte Funktion läuft nun durch (Und sollte die jetzt vemisste Tabelle erzeugen). Laut einem Journal wird sie das aber nicht. Das Journal lege ich mal bei.

Delphi-Quellcode:

    if ConnectContentmasterDB then
    begin
      if ExecuteSQL(CreateTbl_Bld) then
      if ExecuteSQL(CreateTbl_Galery) then
      if ExecuteSQL(CreateTbl_Album) then
      if ExecuteSQL(CreateTbl_bildtext) then
      if ExecuteSQL(CreateTblCSS) then
      if ExecuteSQL(CreateTblJavascript) then
      if ExecuteSQL(CreateTblHtml) then
      if ExecuteSQL(CreateIndexTbl_Html_Tbl_CSS1) then

Das ist die Reihenfolge der Aufrufe. Der Code läüft also durch und die Tabelle wird (scheinbar?) erzeugt. Anbei die Funktion Execute, die das SQL-Statement ausführt

Delphi-Quellcode:

  function TDMLSQLite.ExecuteSQL(ASQL : String) : Boolean;
  begin
    try
      FDSQLiteConnection.ExecSQL(ASQL);
      Result := True;
    except
      on E: EDatabaseError do
      begin
        ShowMessage('Fehler beim Ausführen des Statements:' + #13#13 + ASQL + #13#13 + E.Message);
        Result := False;
      end;
    end;
  end;

Wenn die Tabelle also nicht erzeugt wurde, hätte die Fehlermeldung angezeigt werden müsssen...

Gruss
Delbor

[TigerLilly]

Die Exception würde nur aufgezeigt, wenn sie vom Typ EDatabaseError ist.

Im Attachten Log(?) ist die HTML-Tabelle NICHT zu finden.

Logge doch ALLE Exceptions.