Automatiach erstellte Syntax

[jobo]

Aus Deinem Delphicode geht nun derzeit nicht hervor, was du in den einzelnen Abschnitten wirklich als DML Script übergibst.
Ebenso sehe ich nicht, wo dieser Fehler geschieht (welche Zeile in Delphi).

Also weitere Vermutungen:
Wenn Du lediglich das Attach rausgeworfen hast, den Rest aber belassen wie zu Anfang aufgeführt, ist das logische Schema "ContentMasterData." aus der Create Anweisung nicht mehr bekannt.
Also entweder Attach UND Schemaschreibweise entfernen
oder
beides wie generiert belassen.
oder
Attach weglassen und Schemaschreibweise auf "main".

Betreibt man tatsächlich mehrere DB attachted, kann einem das Weglassen des Schemas offenbar ziemliche Schmerzen verursachen (laut Doku).

[TigerLilly]

Schau dir doch mal an, was in Params - das sollte doch eine StringList sein - wirklich drinsteht:
> DMLSQLite.FDSQLiteConnection.Params.Values['Database']:='M:\SQLite-DB Corner\ContentmasterData\ContentmasterData.sqlite' ;

und zwar vor dieser Zeile:
> DMLSQLite.FDSQLiteConnection.Connected := true;

Welche Delphi Version verwendest du + sind das FireDac Komponenten?

[Delbor]

Hi jobo

Das sind die ersten Zeilen des Scripts, so wie es von Workbench exportiert wurde:

Zitat:

-- Creator: MySQL Workbench 6.3.8/ExportSQLite Plugin 0.1.0
-- Author: Roger
-- Caption: Delbor-Database-Modell
-- Project: DelborpunktCH
-- Changed: 2017-04-18 16:20
-- Created: 2012-06-16 09:09
PRAGMA foreign_keys = OFF;

-- Schema: ContentMasterData
ATTACH "ContentMasterData.sdb" AS "ContentMasterData";
BEGIN;

Davon wurden alle ausser der PRAGMA-Zeile Opfer meines 'Sauberkeitsfimmels'.
Das Script selbst findest du im Anhang.

Zitat:

Aus Deinem Delphicode geht nun derzeit nicht hervor, was du in den einzelnen Abschnitten wirklich als DML Script übergibst.

Alle CREATE TABLE-Konstrukte im Anhang werden einzeln von insgesamt 12 Funktionen zurückgeliefert. ExecSQL führt also im Endeffekt das bis auf die obigen Zeilen (und das commit am Schluss)komplette Script aus.

Zitat:

Ebenso sehe ich nicht, wo dieser Fehler geschieht (welche Zeile in Delphi).

Der Fehler tritt auf, nachdem (oder eben wenn) ExecSQL ausgeführt wird/Werden sollte.

Zitat:

Also entweder Attach UND Schemaschreibweise entfernen
oder
beides wie generiert belassen.
oder
Attach weglassen und Schemaschreibweise auf "main".

ATTACH "ContentMasterData.sdb" AS "ContentMasterData";

Verstehe ich dich richtig? Das würde also z.B. so ausehen:
DMLSQLite.FDSQLiteConnection.Params.Add(ATTACH "ContentMasterData.sdb" AS "ContentMasterData";)
oder:

DMLSQLite.FDSQLiteConnection.Params.Add(main;) Aber vielleicht krieg ich ja doch noch den Durchblick.

TigerLillly schrieb:

Zitat:

Naja, nur, wenn es "Database" schon gibt.

Und die gibts ja auch - nämlich die, welche ich in meinem ersten Post gezeigt habe - die basiert auf der selben sqlite.dll, im selben Anwendungsverzeichnis.
Und genau deswegen muss nun mit Attach die neue DB hinzugefügt werden. Richtig?

Und zu Tigerlilly: Ich hab mir die Params inzwischen angesehen; sie sind auch im Anhang zu finden.

Ich arbeite mit DelphiXE8 unter Firedac.

Gruss
Delbor

[nahpets]

Da mir vollkommen schleierhaft ist, wo denn genau der Fehler nun passiert, mal folgenden Vorschlag einer veränderten Prozedure:

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;

function  TDMLSQLite.ConnectContentmasterDB : Boolean;
begin
  try
    FDSQLiteConnection.Connected := false;
    FDSQLiteConnection.Params.Values['Database'] := 'M:\SQLite-DB Corner\ContentmasterData\ContentmasterData.sqlite';
    FDSQLiteConnection.Params.Values['FailIfMissing'] := 'False';
    FDSQLiteConnection.Params.Values['PRAGMA foreign_keys'] := 'ON';
    FDSQLiteConnection.Connected := true;
    Result := FDSQLiteConnection.Connected;
  except
    on E: EDatabaseError do begin
      ShowMessage('Fehler beim Aufbau der Datenbankverbindung: ' + #13#13 + E.Message);
      Result := False;
    end;
  end;
end;

procedure TDMLSQLite.ContentmasterDBCreate;
begin
  if ConnectContentmasterDB then begin
    if ExecuteSQL(Createbilddescribetabelle) then
    if ExecuteSQL(Createbilddescribetabelle_has_HtmlTabell) then
    if ExecuteSQL(Createbildtabelle) then
    if ExecuteSQL(CreateCSSTabelle) then
    if ExecuteSQL(Creategalerietabelle) then
    if ExecuteSQL(CreateHTMLTable) then
    if ExecuteSQL(CreateJavascriptTable) then
    if ExecuteSQL(Createkategorien_tabelle) then
    if ExecuteSQL(Createkategorien_tabelle_has_bildDescribeTabelle) then
    if ExecuteSQL(CreateMenueTabelle) then
    if ExecuteSQL(CreateSubMenue2Table) then
    if ExecuteSQL(CreateSubmenuetabelle) then ShowMessage('Das war wohl nix!');
  end;
end;

Damit könnte dann erkennbar werden, ob der Fehler bereits bei der Herstellung der Datenbankverbindung auftritt oder erst im späteren Verlauf.
Wenn im späteren Verlauf, wird das fehlerverursachende Statement zusammen mit der Fehlermeldung ausgegeben.

Dies könnte ggfls. die Fehlerursachenforschung deutlich vereinfachen.

Und das ist nur ein Vorschlag, den man strukturell sicherlich noch deutlich verbessern könnte.

Eine noch bleibende Fehlerursache ist, dass bei FDSQLiteConnection.Params.Values davon ausgegangen wird, dass die Paramter schon vorhanden sind. Eventuell zusätzlich vorhandenen Parameter werden nicht geprüft und könnten ggfls. zu unerwünschten Nebenwirkungen führen.

Sinnvoll (und meiner Meinung nach zwingend) ist es, die Parameterliste nach dem Beenden der Verbindung zu leeren und dann die gewünschten Parameter in die Liste einzufügen.
TigerLilly hat da ja, durchaus berechtigt, schon drauf hingewiesen.

Dann schreibst Du einerseits
ATTACH "ContentMasterData.sdb" AS "ContentMasterData";
und andererseits

DMLSQLite.FDSQLiteConnection.Params.Values['Database']:='M:\SQLite-DB Corner\ContentmasterData\ContentmasterData.sqlite';
Wo wird der Zusammenhang zwischen ContentMasterData.sdb und ContentmasterData.sqlite hergestellt?
Das ist mir nicht klar, könnte das gglfs. eine Fehlerursache sein?

Zumindest hätte ich da eher sowas erwartet:

ATTACH "ContentMasterData.sqlite" AS "ContentMasterData";
Aber da mag ich mich wohl auch irren.

[TigerLilly]

Ich weiß nicht recht, irgendwas geht da durcheinander.

DMLSQLite.FDSQLiteConnection.Params nimmt NUR angaben zur Verbindung zur Datenbank auf. Ein Attach hat da nichts verloren.
Im Screenshot ist eine Datenbank mit .db angegeben, im Code .sqlite. Ist das ein Typo?

Gibt es die Datenbank nicht, so wird sie angelegt. Ich glaube, das hattest du gesagt, dass das passiert.

Der Fehler tritt auf, sobald connected auf true gesetzt wird - richtig? Oder erst später, bei den SQL Statements?

Das ATTACH gehört jedenfalls zu den SQL Anweisungen.

Möchtest du die .db öffnen oder die .sqlite?
Warum öffnest du eine andere DB als du dann bearbeiten willst (=die die du mit ATTACH öffnest)?

[p80286]

Das was Jobo oben geschrieben hat etwas anders formuliert.

Wenn ich das richtig interpretiere,#14, dann wurde in der Datei .....Contentmaster\Contentmaster.sqlite
eine dataBase mit dem namen "main" angelegt.
Jetzt gibt es zwei Möglichkeiten:
a) nach dem Connect wird mit "main" gearbeitet, also Create Table "main.meinetabelle" ..... oder
b)das ATTACH Statement wird ausgeführt, dann kann man auf "Contentmaster.Meinetabelle" zugreifen.
Create Table "Contentmaster.Meinetabelle" ..... Eine (SQL-)DATABASE is eine logische Struktur deren physikalische Struktur eine Datei sein kann, aber nicht sein muß. Bevor Du mit der logischen database arbeiten kannst, mußt Du ihr einen phys. Speicher zuweisen bzw. wenn Du eine Datei hast muß diese mit einem Name, der DATABASE versehen werden.

Ich hoffe, das ist einigermaßen verständlich.

Gruß
K-H

[jobo]

Zitat von p80286:

Das was Jobo oben geschrieben hat etwas anders formuliert.

Genau.

Ich schätze das Problem hier ist:
Das verwendete Tool generiert ein Script, Delphi SQL Componenten arbeiten aber meist Statement basiert.
Die Vermischung (oder (unvollständige) "Säuberung") von Script Elementen ist kontraproduktiv.

Kurze Lösung, lade Dir (wenn nicht vorhanden) sqlite3.exe und rufe folgendes aus einer cmd box auf:

Code:

sqlite3 testdb < script.sql

wobei in der Notation alles in einem Verzeichnis liegen muss oder sqlite3.exe im Suchpfad stehen muss.
testdb = irgendeine nicht existierende Datei
script.sql = Dein Script wie es von deinem Konvertierungstool ausgespuckt wurde.

Wenn in dem Rest (nicht von Dir veröffentlicht) keine Fehler des Konvertierungstools stecken wird es einfach durchlaufen.
Anschließend hast Du jenachdem mindesten eine Datei mehr in dem Verzeichnis, nämlich "ContentMasterData.sdb"

Ich habe hier deine Vorgabe noch etwas erweitert. Probier es mit der Kommandozeile oben aus, dann wird Dir auch klar, was es mit Deinen Connectioneinstellung in den Delphikompos auf sich hat. Schau dann mal in die Datei 'testdb' rein, mit einem sqlite tool.
Und natürlich in die Datei ContenMasterData.sdb.

Code:

-- keine fk prüfung
PRAGMA foreign_keys = OFF;
-- ist sowieso egal ohne definierte fk

-- benutze Datei ContenMasterData.sdb und nimm den logischen Bezeichner ContentMasterData
ATTACH "ContentMasterData.sdb" AS "ContentMasterData";
BEGIN;
CREATE TABLE "ContentMasterData"."bildtabelle"(
                                "idBild" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL CHECK("idBild">=0),
                                "Thumbnail" BLOB,"Bitmap" BLOB,
                                "Jpeg" BLOB,
                                "FolderId" VARCHAR(32));


CREATE TABLE "ContentMasterData"."galerietabelle"(
                                "Gallery_ID" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL CHECK("Gallery_ID">=0),
                                "GalleryName" VARCHAR(50));

CREATE TABLE "ContentMasterData"."CSS-Tabelle"(
                                "idCSS" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL CHECK("idCSS">=0),
                                "PageCSS" LONGTEXT NOT NULL,"MenueCSS" LONGTEXT NOT NULL); 
                                
insert into ContentMasterData."bildtabelle" ("Jpeg" , "FolderId" ) values( null, '../das/ist/ein/Relativpfad/xy.jpg')     ;

-- mal ohne die Anführungszeichen
insert into ContentMasterData.galerietabelle (GalleryName ) values( 'Erste Bildreihe');    
      
-- "sonderzeichen" geht nicht ohne Anführungsstriche 
insert into ContentMasterData."CSS-Tabelle" (PageCSS , MenueCSS ) values( 'some page css', 'some menu css');

-- jetzt mal ohne die Schemaangabe
create table jobotesttable (aID integer, aText varchar(50));
insert into jobotesttable values (1,'jobo');

-- dedizierter, logischer Zugriff auf default aka main Schema
insert into main.jobotesttable values (null,'main.Jobo');

end;

Wenn Du mit Delphi auf ContentMasterData verbinden willst, per DelphiCode bzw. Properties, nimmst Du das vorweg, was das Script selbst macht. Das funktioniert sicher nicht gut. Die Komponenten kenne ich nicht, deswegen kann ich Dir dazu nichts sagen.
Letztlich würde ich meinen Tipp wiederholen, hier nicht groß mit Delphi rumzuwirbeln, sondern per Command Line das Script laufen zu lassen. Notfalls per ShellAPI innerhalb Deines Programms.

Achso und nochmal anders formuliert.
Wenn Du attach weglässt, dann lasse auch die vorgeschaltete Schemabezeichnung in den restlichen Scriptanweisungen weg.
Zum Spaß kannst Du ja auch noch mal Dein Konvertierungstool anwerfen und 2 Datenbanken scripten lassen. Im Ergebnis wird dann vielleicht auch klarer, was das Teil mit dem attach macht.

[jobo]

Und irgendwo stand noch, dass man die Daten nicht mit Transkationen lädt.

Ich würde sagen, natürlich macht man das. Dafür sind sie da.
sqlite schwächelt da leider und verhält sich nicht so, wie das m.E. sein soll.
Ist aber ein anderes Thema. Kann man ja bei Bedarf separat klären.

[Delbor]

Hi zusammen

Nach längerm Suchen (inklusive überlesen...) hab ich da was interessantes gefunden:

Zitat:

Verwenden von mehreren SQLite-Datenbanken in einer Delphi-Anwendung

SQLite ermöglicht die Verwendung mehrerer Datenbanken in einer einzelnen Verbindung. Eine im Parameter Database angegebene DB ist die Hauptdatenbank. Um weitere Datenbanken hinzuzufügen, muss in der Delphi-Anwendung die ATTACH-Anweisung verwendet werden. Zum Beispiel:

Delphi-Quellcode:

 FDConnection1.ExecSQL('ATTACH ''c:\hr.sdb'' AS hr');
 FDConnection1.ExecSQL('ATTACH ''c:\cust.sdb'' AS cust');
 FDQuery1.Open('select * from "Orders" o ' +
   'left join hr."Employees" e on o.EmployeeID = e.EmployeeID ' +
   'left join cust."Customers" c on o.CustomerID = c.CustomerID');

Mit der von mir immer wieder erwähnten Connection-Komponente hab ich die Eingangs gezeigte DB erstellt. Laut diesem Artikel ist dies somit die 'Hauptdatenbank' in dieser Verbindunng. Alle weiteren Datenbanken müssen nun also mit ATTACH der Verbindung hinzugefügt werden.
Dies hatte ich ja erstmal so versucht:

DMLSQLite.FDSQLiteConnection.Params.Add('ATTACH "ContentMasterData.sdb" AS "ContentMasterData";');

Tigerlilly meinte dazu:

Zitat:

DMLSQLite.FDSQLiteConnection.Params nimmt NUR angaben zur Verbindung zur Datenbank auf. Ein Attach hat da nichts verloren.
Im Screenshot ist eine Datenbank mit .db angegeben, im Code .sqlite. Ist das ein Typo?

Hmm, Tigerlilly, in welchem Screenshot? Die eingeschwärzten Bildschirmschüsse zeigen ewinen Ausschnitt meiner Programmoberfläche. Das kann ein Tippfehler sein, ist aber wohl eher ein C&P-Fehler.

Gemäss dem oben gezeigten Codeschnipselfund werde ich jetzt erstmal zusehen, dass ich die ATTACH-Anweisung richtig hinkrieg.

Zitat von Jobo:

Zitat:

Ich schätze das Problem hier ist:
Das verwendete Tool generiert ein Script, Delphi SQL Componenten arbeiten aber meist Statement basiert.

Was ist denn der Unterschied zwischen einem Script und einem SQL-Statement? Nach meiner Interpretation erstmal wohl keiner; beide sind reiner Asccii-Text und werden interpretiert.
Wobei ein VB-Interpreter mit Select wohl erst mal nicht viel anfangen kann, eine SQL-Engine hingegen mit Dim hingegen genauso überfordert ist. Wobei der VB-Interpreter ein Select-Statement als String entgegennehmen und ihn an die SQL-Engine weiterreichen kann.

So, wie ich das sehe, enthält dieses Script nichts weiter als ein mehr oder weniger komplexes SQL-Statement, um damit mit der SQLite-Engine (SQLite3.dll) eine SQLite-DB zu erstellen.

Im Anhang zeigt ein jpeg die auf meinem System gefundenen sqlite.exe-Dateien, wobei mindestens eine davon eine Installationsdatei ist.


Gruss
Delbor

[TigerLilly]

Ja, genau. Das ATTACH muss aber mit ExecSQL ausgeführt werden, nicht in den Params.

Der Unterschied zwischen SQL Abweisung und SQL Script ist nur, dass eine SQL Anweisung eine einzelne Anweisung ist, das Script aber aus mehreren Anweisungen besteht. In der Regel ist das für die Delphi Komponenten kein Unterschied, weil der ganze Text an die Datenbank zur Abarbeitung geschickt wird.

Ich habe es jetzt nicht im Kopf, aber es kann vereinzelt ein Problem mit einem Script geben, wenn Delphi das SQL Statement parsen muss, um zB Parameter zu setzen oder ein Update-SQL zu generieren. Oder wenn Feldnamen extrahiert werden müssen. Aber das ist da ja nicht der FAll.

Ich persönlich mag es lieber, wenn die Statements einzeln ausgeführt werden, dann sehe ich besser, wo ein Fehler auftritt + ich kann auch nach jedem Statement dem Benutzer Feedback geben + den Fortschritt anzeigen.