MSSQL Replikation

[Uwe Raabe]

Zitat von haentschman:

Vieleicht hat mir geholfen daß ich die SQL in Dateien/Ressourcen gespeichert habe.

Wenn man es genau nimmt, dann speichert derjenige, der das SQL z.B. im gleichnamigen TFDQuery-Property einträgt, das ja auch in einer Ressource:

Delphi-Quellcode:

{$R *.dfm}

[jobo]

Zitat von Uwe Raabe:

Zitat von haentschman:

Vieleicht hat mir geholfen daß ich die SQL in Dateien/Ressourcen gespeichert habe.

Wenn man es genau nimmt, dann speichert derjenige, der das SQL z.B. im gleichnamigen TFDQuery-Property einträgt, das ja auch in einer Ressource:
..

Let's get nerdy!
Uwe hat Recht, aber da würde ich anmerken, Ressource ist nicht gleich Ressource.
Wenn man ausschließlich mit Delphi arbeitet, spielt der Zugang und die Änderbarkeit der Ressourcen nicht so eine große Rolle. Im Gegenteil, manchmal ist ja die Möglichkeit, alles in einer Anwendung zu integrieren (und as is auszuliefern) auch sehr gewollt und mit der resultierenden Statik auch besonders robust.
Bedeutet aber auch, dass Ressourcenänderungen mit der Neukompilation und Verteilung verbunden sind (außer, man fährt da mehrgleisig, womit der Faktor Robustheit an der Stelle aber auch hops geht.)
Ich kenne die Komponenten von haentschan nicht, aber Zugängigkeit und Dynamik der (ausgelagerten) Ressourcen sehe ich jedoch als wichtigen Faktor. Und mal kurz durchgespielt: Wenn ich mit transparent zugängigen, externen Ressourcen loslege, ist es aus dieser Richtung auch nicht sehr aufwändig, bei Bedarf Ressourcen zu embedden, automatisert und mir klaren Verantwortlichkeiten. Da würde mir ein Ressourcenmanager wie von haentschman wahrscheinlich besser gefallen, als ein *.dfm.

[haentschman]

Zitat:

Ich kenne die Komponenten von haentschan nicht

...keine Komponenten. Einfach SQL Files die eingebunden werden.
Anleitung:
https://www.delphipraxis.net/49505-s...einbinden.html

Zitat:

besser gefallen, als ein *.dfm.

...sucht sich leichter und ist von der verwendeten Komponente nicht abhängig.