Originally Posted by
luigi
Als ik het rapport designtime maak dan maak ik hier ook drie queries aan die ik dan op de juiste wijze koppel. Als ik dit runtime wil doen zal ik ergens die relatie tussen de queries moet vastleggen.
Ja, dat kun je ook runtime doen. Maar omdat, als je zelf al verschillende queries (en SQL) vast zet in je programma, dan kun je dat net zo goed designtime doen.
En als je het helemaal variabel wil maken met elke denkbare SQL dan moet je van het idee van master/detail afstappen of gaan werken met een echte rapport-generator zoals FR.
Maar als ik je goed begrijp zeg je dat ik gewoon een grote join moet maken van factuur, factuur regel en factuur regel BTW?
Ja, ik doe dat dan met joins en unions.
SQL Code:
SELECT a.factuurnummer, b.subregel, b.bedrag
FROM factuur a
LEFT JOIN b ON b.factuurnummer=a.factuurnummer
Als je dan ook totalen wilt hebben wordt het wat moeilijker en moet je met unions gaan werken.
SQL Code:
SELECT a.factuurnummer, 1, b.subregel, b.bedrag
FROM factuur a
LEFT JOIN b ON b.factuurnummer=a.factuurnummer
union ALL
SELECT a.factuurnummer, 2, sum(b.bedrag)
FROM factuur a
LEFT JOIN b ON b.factuurnummer=a.factuurnummer
union ALL
SELECT a.factuurnummer, 3, '------- scheiding ------'
FROM factuur a
ORDER BY 1, 2
Bovenstaand gewoon even uit de vuist getikt dus onderhevig aan fouten
Een echte rapportgenerator geeft je natuurlijk veel meer vrijheid om ingewikkelde lijsten te maken die je met een enkele DBGrid niet kunt maken. Maar voor mij geeft de mogelijkheid van het zelf maken van SQL weer enorme vrijheid (je hoeft niet te gaan klungelen met een generator en sjabloon om een semi-ingewikkelde SQL-lijst te maken).
Bookmarks