FireDAC Makro vs Parameter

[Der schöne Günther]

Ok, das wäre meine nächste Frage gewesen. Danke fürs Gedankenlesen

[Elrond]

Auch von mir ein Danke für die kompakte Erklärung.

[dataspider]

Makro braucht man dann, wenn man nicht Werte, sondern z.B. Feldnamen oder komplexe Teile ersetzen muss.

Beispiel: select * from rechnung where mandant_nummer in <<nummern>>.

Dann kann man <<nummern>> ersetzen durch ('300', '301', '400').

Das geht mit Params nicht.

Frank

[haentschman]

Moin...
Ich mache ja ungern die Spaßbremse. So schön wie das alles ist, du bindest dich mit Macros ausschließlich an diese Komponente. Für meinen Teil schwöre ich auf klassisches SQL mit klassischen Querys. Mit einer ausgetauschten Deklaration habe ich einen Komponentenwechsel (sinngemäß)...

[Elrond]

Zitat von haentschman:

Moin...
Ich mache ja ungern die Spaßbremse. So schön wie das alles ist, du bindest dich mit Macros ausschließlich an diese Komponente. Für meinen Teil schwöre ich auf klassisches SQL mit klassischen Querys. Mit einer ausgetauschten Deklaration habe ich einen Komponentenwechsel (sinngemäß)...

In der Regel ist das auch meine bevorzugte Herangehensweise. Jedoch stehe ich aktuell vor der Anforderung mindestens drei unterschiedliche Datenbanksysteme zu unterstützen. Würde ich auf reines SQL zurückgreifen müsste ich für jede DB alle Querys unter Beachtung der Syntaxregeln neu schreiben, hinzukommt noch die individuelle Unterstützung von Transaktionen. Am ende hätte ich meinen eigenen DAC Derivaten.

[Uwe Raabe]

Nach meiner Erfahrung wechselt man die DAC-Komponente ja auch nicht so häufig wie z.B. die Datenbank oder die Delphi-Version. Eine Umstellung ist da schon ein ziemliches Unterfangen und kann durchaus mehrere Monate dauern. Das macht man nicht mal eben so aus einer Laune heraus. Erfreulicherweise deckt FireDAC ja ein sehr breites Spektrum ab und bietet einen durchaus brauchbaren Funktionsumfang. Damit lässt sich bei Ausnutzung der verfügbaren Möglichkeiten auch weitestgehend datenbankunabhängig entwickeln.