Kijk, nu zeg je iets heel anders. en snap ik waarom je geen resultaat hebt. Of ik je kan helpen, is, zonder de db te zien, daarmee overigens nog lang niet gezegd. Jammer dat je vasthoudt aan het (vereenvoudigde?) voorbeeld van een tabel met één veld en een query met één veld. Want nu weet ik nog steeds niet of die situatie ook in de praktijk geldt, of dat je dan andere constructies gebruikt of nodig hebt. Misschien bestaat de 'ingewikkelde' query uit meerdere tabellen en queries, die allemaal met één veld in de uiteindelijke query terecht moeten komen, en lukt het al niet om één tabel met één query te koppelen.
Eerst maar even uitleggen waarom het nu niet werkt, wellicht dat je dan snapt dat je iets anders moet doen. Zodra je als outpunt één record wilt, moet de onderliggende bron dat wel kunnen leveren. De tabel en query zijn niet gekoppeld, zei je, dus als je de twee benodigde velden (uit tabel en Query) naast elkaar zet en de twee velden hebben allebei een waarde, dan krijg je het Cartesisch Product. Omdat beide queries maar één record hebben, en je één veld gebruikt, is dat niet zo erg, want er is maar één combinatie mogelijk van de bronnen. Als één van de bronnen echter leeg is, en dat lijkt dus voor te komen, kan er geen record worden gemaakt, puur op grond van het feit dat je niet iets kunt maken van iets dat er niet is. Je zult er dus voor moeten zorgen dat de query nooit leeg kan zijn. Desnoods gebruik je een formule om, bij een lege uitkomst, een tekst te laten zien. Zolang er maar een record is, krijg je dan een output. Vergelijk het met een Word document. Daarin heb je altijd minstens één pagina, en één alinea. Zonder die ene alinea kun je geen tekst typen, zonder die ene pagina heb je niet eens een document. Het ding bestaat dan namelijk niet.
De oplossing is er eigenlijk niet, behalve dus zorgen dat je data in orde is en er geen lege queries zijn. Ik denk dat een Union query ook geen oplossing voor je is, omdat je daarmee weliswaar alle beschikbare data in een tabel krijgt (ok, onder elkaar i.p.v. naast elkaar) maar omdat in dat geval een lege query wordt overgeslagen, is de recordpositie van de resterende velden nooit identiek; stel dat je 3 queries probeert te koppelen met twee tabellen, en de tweede query is leeg. Dan krijg je geen 5 rijen, zoals je zou willen, maar 4. Daarbij schuift de derde query dan een rij op. En lijkt het dus alsof je 4 rijen hebt in de output. In het voorbeeldje ziet dat er dan zo uit, waarbij :
Code:
SELECT [_t1].MedewerkerID FROM _t1
UNION SELECT [_t2].BedrijfID FROM _t2
UNION SELECT [_q1].Omzet FROM _q1
UNION SELECT [_q2].Winstpercentage FROM _q2
UNION SELECT [_q3].NettoWinst FROM _q3
Wat dan dit oplevert:
En dat wil je dus niet zien. Want daar kun je geen rapport van maken, omdat de output niet betrouwbaar is. Voordat ik doorga met een (mogelijke) oplossing (meer een workaround), moet je toch eerst wat meer vertellen, want ik snap dus totaal niet wat je aan het doen bent, en het oogt als een ongelooflijk ingewikkelde constructie allemaal... En daarbij denk ik dan uiteraard als eerste: kan dat niet simpeler?
. Je eerste bericht (met de typfouten) snapte ik wel, de tweede eigenlijk niet? En dat komt hierdoor:
