Thank you, Karl. Your answer regarding "being too complex" addressed the
previous problem I had before I tried this current work around. It sounds
like I may be pushing the envelope in terms of the coding of the SQL
statement. That is helpful. Being I am using the Design view and not the SQL
view it appears to be limitless in its design. However, it sounds like I am
learning there are limitations in using SQL. I am not an SQL programmer
unfortunately.
This is what I am trying to do. My database contains a report with a series
of sub-reports. However, my customers would like the data in an editable
format where they can take portions of my report and post them into their
existing Excel workbooks.
To do so and not create additional steps for myself at the same time, I
assembled a query that pulls all the queries that populate that report
together into a master query, so to speak, where they can now open a query
datasheet of all the sub query results which they can then copy/paste into an
Excel book versus the Access report which is not designed to copy/paste data
I will await any suggestions to fulfill this process being this is something
the management teams like about what Access can do (and that was a major feat
for this office where they are absolutley terrified of Access.) In the
meantime, I am going to tweak perhaps create a pyramidal style where instead
of using all 16 queries in one I will split them into two and then have those
two go into one in some fashion.
Thanks again, Karl, for your response. If what I have written here sparks
something of an idea, I would appreciate your feedback.
Rick