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.