SQL Statement speichern

[Graw]

Hallo,

bislang habe ich SQL Statements immer in der Registry gespeichert.
Nun würde ich sie gerne in einer .ini ablegen.
Allerdings funktioniert das einlesen sehr schlecht.
Entweder es fehlen Teile des Statements oder die Formatierung ist komplett falsch.

Wie speichert ihr SQL Statements? Es gibt sicherlich besserer Methoden.

Danke

[haentschman]

Moin...8-)

Mein Favorit ist: Speicherung der SQL in Ressourcen...:thumb:

Tool dazu: https://www.delphipraxis.net/190316-...e-creator.html -> DP Lizent per PN (Mail)

[Graw]

Nutze nun einfach Memo.Lines.LoadFromFile bzw. Memo.Lines.SaveToFile.
Ich denke damit klappt es gut.

Trotzdem Vielen Dank.

[haentschman]

Zitat:

Ich denke damit klappt es gut.

...glaube ich nicht. :warn: Damit ist SQL Injection Tor und Tür geöffnet! https://de.wikipedia.org/wiki/SQL-Injection

[Uwe Raabe]

SQL-Injection hat lediglich was mit dem Aufbau des SQL zu tun und weniger wie und wo es gespeichert wird. Ein schlampig geschriebenes SQL wird auch nicht dadurch sicherer dass man es als Ressource in der Exe speichert.

[Jasocul]

Zitat:

Zitat von Uwe Raabe (Beitrag 1525591)

SQL-Injection hat lediglich was mit dem Aufbau des SQL zu tun und weniger wie und wo es gespeichert wird. Ein schlampig geschriebenes SQL wird auch nicht dadurch sicherer dass man es als Ressource in der Exe speichert.

Das stimmt natürlich, aber ein SQL-Statement als Klartext in einer Datei zu speichern, ist an Risiko kaum zu übertreffen. Fehlt eigentlich nur noch eine zweite Datei mit dem Connectstring inklusive Passwort.:roll:

Ich speichere SQL-Statements vollständig parametrisiert auch als Ressource.

[Uwe Raabe]

Zitat:

Zitat von Jasocul (Beitrag 1525592)

Das stimmt natürlich, aber ein SQL-Statement als Klartext in einer Datei zu speichern, ist an Risiko kaum zu übertreffen.

Wenn jemand böses Zugriff auf das System hat und die Datei zu manipulieren kann, dann ist man eh schon aufgeschmissen. Gegenüber der aktuell verwendeten Registry ist das kein großer Unterschied. Eine Ressource lässt sich da fast ebenso leicht durch eine bösartige Ressourcen-DLL (z.B. mit DE Extension) neben der EXE unterwandern. Den dafür eventuell eingerichteten Zugriffsschutz kann man dann ja auch für die INI-Datei einrichten, dann sind beide Verfahren gleich (un-)sicher.

Bei SQL-Injection geht es aber gar nicht um die Manipulierung der SQL-Anweisung an sich, sondern um die Verfälschung durch bösartige Eingaben, ob die nun vom User am lokalen Rechner, einer importierten Datei oder über die Eingabe auf einer Webseite kommen. Das Speichern der SQL-Anweisung in einer INI-Datei öffnet also mitnichten einer SQL-Injection Tür und Tor. Das ist nur von der SQL-Anweisung selbst abhängig - der Speicherort hat damit überhaupt nichts zu tun.

[freimatz]

Unsere App benutzt zwar intensiv DBs, aber ich habe direkt recht selten mit SQL zu tun. Interessehalber die Frage: wieso sollte man SQL Statements in der Registry oder in einer Ini speichern? Ich kenne das halt so, dass diese in den DB-Komponenten direkt gespeichert ist oder der SQL-Code mittels Delphi-Code zuusammengebaut wird.

[Uwe Raabe]

Zitat:

Zitat von freimatz (Beitrag 1525594)

Ich kenne das halt so, dass diese in den DB-Komponenten direkt gespeichert ist oder der SQL-Code mittels Delphi-Code zuusammengebaut wird.

Das ist ein sehr verbreiteter und durchaus valider Ansatz. Damit wird auch der Live-Zugriff zur Designzeit ein Kinderspiel. Solange keine anwenderspezifischen SQL-Besonderheiten berücksichtigt werden sollen, ist das auch mein persönlich präferierter Ansatz.

[Jasocul]

Zitat:

Zitat von freimatz (Beitrag 1525594)

Unsere App benutzt zwar intensiv DBs, aber ich habe direkt recht selten mit SQL zu tun. Interessehalber die Frage: wieso sollte man SQL Statements in der Registry oder in einer Ini speichern? Ich kenne das halt so, dass diese in den DB-Komponenten direkt gespeichert ist oder der SQL-Code mittels Delphi-Code zuusammengebaut wird.

Bei kleinen Anwendungen oder wenigen SQL-Statements innerhalb der Anwendung geht das noch. Aber irgendwann fängt man an, für jede "abweichende" Abfrage ein neues TQuery ins DataModule zu packen. Ich habe schon DataModule gesehen, auf denen soviele Queries drauf waren, dass niemand mehr wusste, wo was drin steht. Durch die große Menge stehen die dann manchmal schon außerhalb des Canvas.
Dazu kommt, dass diese Statements im DFM stehen. Versuche mal nach Schlüsselbegriffen im Statement zu suchen. Innerhalb von Delphi geht das gar nicht (@Uwe: Ich kenne da zumindest nichts) und wenn man "von außen" sucht, findet man oft die Begriffe nicht, weil im DFM mittendrin umgebrochen wird.

Manche Statements müssen tatsächlich im Source zusammengebaut werden, aber die meisten sind relativ statisch, wenn man weiß, wie man mit SQL umgeht und müssen nur gut parametrisiert werden. Es gibt auch genügend Möglichkeiten solche Sachen in der Datenbank abzulegen (Stored Procedures, User Defined Functions, Views, etc.). Eine Ablage in INI-, SQL-Dateien oder in der Registry halte ich (ist meine ganz persönlich Ansicht!) für unprofessionell.

Wie weiter oben schon geschrieben, lege ich die Statements als Ressource oder in einer Datenbank ab.

Den Vorteil des Live-Zugriffs zur Designzeit, wie Uwe Raabe geschrieben hat, kann man trotzdem erhalten und sogar noch optimieren. Man nimmt dafür einfach ein SQL-Statement für die DB-Komponente, welches zur Laufzeit nie aufgerufen wird. Mit einer passenden Where-Bedingung erhält man 0 Datensätze, dafür aber alle notwendigen Felder ohne große Laufzeit der SQL-Abfrage.
Zur Laufzeit werden dann die "echten" Statements geladen.