Die Problematik mit den Anführungsstrichen wäre ein gutes Beispiel für ungewollte Effekte, die durch Toolfehler oder Fehlkonfiguration eines Tools entstehen können.
Diese oder ähnliche Form von Delimiterangaben für Feldnamen sind idR überflüssig, wenn man auf Leerzeichen und nationale Zeichen in den Feldnamen verzichtet. Auch wenn wir im Jahr 2000 ++ leben, ist die Verwendung von reinen
ASCII Bezeichnern immer ne gute Wahl (plus einheitliche Sprache).
Die Pragmaanweisungen muss man prüfen. Wenn man keine Foreign Keys will, schaltet man sie aus, wenn man sie will, schaltet man sie ein. Sollte eigentlich so laufen, wie dort geschrieben.
Die pauschale Abschaltung von Foreign Keys würde man höchstens für einen komplizierten Import mit rekursiven Bezügen machen. Und am Ende dann die Bezüge aktivieren. Wofür braucht man sonst Foreign Key Definitionen?
Was das Tool ausspuckt ist ein komplettes Create Script. Also mehr als eine Anweisung. Soetwas läuft idR nicht mit den normalen Delphi
Query Komponenten. Ein solches Script wird in diesem Fall hier z.B. mit SQLITE.EXE eingespielt oder sonst irgendeinem scriptfähigen Tool per Kommandozeile oder interaktiv. Für Delphi gibt es vielleicht auch dafür Scriptkomponenten, weiß ich nicht.
Ansonsten muss man das Script in seine Einzelteile (Einzelanweisungen) zerlegen, wenn es mit Delphi Queries eingespielt werden soll.
Pragma Foreign Keys = Off scheint im Übrigen genau so ein Fall zu sein, wo ein Tool eine Defaulteinstellung einer
DB nachahmt. Genau auf sowas bezog sich mein Beitrag, man sollte genau schauen, "wer" aus welchem Antrieb bestimmte Dinge im Datenmodell setzt.
Zitat
Baum-Darstellung
