Fehler in SQL-Syntax

[hsg]

Alternative zur Speicherung in Dateien: Speicherung in einer Datenbank-Tabelle
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.

[Delbor]

Hi TigerLilly

Zitat:

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

Genau desshalb denke ich eigentlich, dass die Tabelle gar nicht erstellt wurde. Somit kann sie auch nicht gefunden werden. Mich irritiert aber, das die Connection nicht reklamiert...

Gruss
Delbor

[TigerLilly]

Wie gesagt, gib ALLE Exceptions aus, nicht nur EDatabaseError.

[nahpets]

Der Rückgabewert der Funktion ist nur False, wenn ein Datenbankfehler geworfen wird. In anderen Fällen ist Result entweder True oder undefiniert.
(Eigentlich müsste es eine entsprechende Compilermeldung geben - Rückgabewert könnte undefiniert sein. o. ä .)

Wenn FDSQLiteConnection.ExecSQL(ASQL) ausgeführt wird und keine Exception fliegt, ist der Rückgabewert der Funktion true, unabhängig davon, ob das erwartete erledigt wurde oder nicht.

Delphi-Quellcode:

function TDMLSQLite.ExecuteSQL(ASQL : String) : Boolean;
begin
  Result := False;
  try
    FDSQLiteConnection.ExecSQL(ASQL);
    // Hier sollte man noch prüfen, ob das, was in ASQL gemacht werden
    // soll, auch wirklich gemacht wurde.
    // Bei Insert, Update und Delete findet man die Anzahl der
    // Änderungen in RowsAffected.
    // Bei 'ner Tabelle, die erstellt werden sollte, könnte man noch ein
    // select * from tabelle
    // hier ausführen und nur, wenn das erfolgreich ist folgt:
    Result := True;
  except
    on E: EDatabaseError do begin
      ShowMessage('Fehler beim Ausführen des Statements:' + #13#13 + ASQL + #13#13 + E.Message);
    end;
  end;
end;