union query in access too complex for evaluation

Question

I am getting following error in access and I do not know why. I'll translate it from Dutch:

"Deze expressie is niet correct getypt of te complex voor evaluatie.
Een numerieke expressie kan bijvoorbeeld te veel gecompliceerde elementen bevatten.
Probeer de expressie te vereenvoudigen door verschillende delen van de expressie toe te wijzen aan variabelen."

English:

"This expression has a spelling error or is too complex for evaluation.
A numeric expression could contain to many complex elements.
Try to simplify the expression by assigning several parts to variables."

The weird thing is that my query's work seperately. The error only occurs from the moment I use the UNION function. Since they work seperately I do not think this is a typing mistake? Tree query is an other query which generates a tree. (3 tables linked with id and arent id)

Alle other tables are just data.

SELECT "(z) Opleidingen" AS Campaign, LCase([Tree query]![sector] & "#" & IIf([Tree query]![cluster] Is Null, [Tree query]![subsector],[Tree query]![cluster])& "$" & [Opleidingsnaam]![Collinaam]) AS Adgroup, "Broad" AS [Keyword Type], "0,60" AS [Max CPC], [Opleidingsnaam]![URL] AS [Destination URL], "+" & Replace([Opleidingsnaam]![Opleidingsnaam]," "," +") & " +" & Replace([Locatie]![Keyword]," "," +") AS Keyword, "Active" AS [Keyword Status], Opleidingsnaam.Timestamp AS t1, Locatie.Timestamp AS t2, Null AS t3, Null AS t4, Null AS t5
FROM Locatie, Opleidingsnaam INNER JOIN [Tree query] ON Opleidingsnaam.SectorId = [Tree query].ID
WHERE (((Opleidingsnaam.Timestamp)>[inputdate]) AND ((Opleidingsnaam.Startdatum)>[inputdate])) OR (((Locatie.Timestamp)>[inputdate]) AND ((Opleidingsnaam.Startdatum)>[inputdate])) OR (((Null)>[inputdate]) AND ((Opleidingsnaam.Startdatum)>[inputdate])) OR (((Null)>[inputdate]) AND ((Opleidingsnaam.Startdatum)>[inputdate])) OR (((Null)>[inputdate]) AND ((Opleidingsnaam.Startdatum)>[inputdate]));


UNION


SELECT "(z) Opleidingen" AS Campaign, LCase([Tree query]![sector] & "#" & IIf([Tree query]![cluster] Is Null,[Tree query]![subsector],[Tree query]![cluster])& "$" & [Opleidingsnaam]![Collinaam]) AS Adgroup, "Broad" AS [Keyword Type], "0,60" AS [Max CPC], [Opleidingsnaam]![URL] AS [Destination URL], "+" & Replace([Opleidingsnaam]![Opleidingsnaam]," "," +") & " +" & Replace([Campus]![Keyword]," "," +") AS Keyword, "Active" AS [Keyword Status], Opleidingsnaam.Timestamp AS t1, Campus.Timestamp AS t2, Null AS t3, Null AS t4, Null AS t5
FROM Campus, Opleidingsnaam INNER JOIN [Tree query] ON Opleidingsnaam.SectorId = [Tree query].ID
WHERE (((Opleidingsnaam.Timestamp)>[inputdate]) AND ((Opleidingsnaam.Startdatum)>[inputdate])) OR (((Campus.Timestamp)>[inputdate]) AND ((Opleidingsnaam.Startdatum)>[inputdate])) OR (((Opleidingsnaam.Startdatum)>[inputdate])) OR (((Null)>[inputdate]) AND ((Opleidingsnaam.Startdatum)>[inputdate])) OR (((Null)>[inputdate]) AND ((Opleidingsnaam.Startdatum)>[inputdate]));

Can somebody please help me with this. It is driving me crazy :)

Background: I am using the union query to combine several queries. The queries combine different tables which contain keywords. I want to create all possible keyword combinations. This I use within Google Adwords.

Thanks in advance!

Answer 1

UNION queries are not easy to troubleshoot. I think @GarethD is right - to give you the best chance, you should:

1. Save each query (double-check that each has the same number of fields)
2. Change your UNION query to be SELECT * FROM Query1 UNION SELECT * FROM Query2...

With no joins, you are using the Cartesian product, which takes up a lot of memory. I suspect that even this will not fix your problem. If this does not work, you may need to use an ugly hack - loop through all of the queries and append the results to a temporary table.

Answer 2

I was having the problem and added ',*' to the end of the select clause. It worked, but I noticed that for some reason it only added one field, used as a WHERE criteria in the underlying queries. I then removed the * and added in that one field. Hey presto, all working. So my conclusion was that underlying WHERE fields need to be included. Pity that JET gets less reliable with every release.