Dear Chris:

Your next project sounds somewhat interesting.

I believe I am leaning toward having a local table to store the user's
selected check boxes (booleans). This local table would be created or
cleared when the form is entered. It would need whatever columns uniquely
identify the row being selected.

You would clear and repopulate this table when the form is entered, or
whenever the set of rows displayed on the form changes, depending on how the
design functions in this respect.

By using a local table, two different users could create reports on
different computers independently.

Sounds like a moderate challenge to me.

Tom Ellison


"Chris W via AccessMonster.com" u12677@uwe wrote in message
news:55c2a7bd97aae@uwe...
That really does make a lot more sense I hadn't really though of the WHERE
clause of the SQL as EXCEPT WHERE or as you put it NOT clause, though I
don't think I am ready for in depth programming.

In terms of the next part of the query I really have it operating the way
it
should at the moment and I am becoming extremely restricted for time as
this
was only ever meant to be a side project that has progressed to a full
blown
obsession.

Having said that the only other thing that I am interested in creating,
though again I don't even know if this is even possible to do let alone in
a
timely fashion.

I am interested in creating a 'shopping basket' feature to a query, where
the
retuned records from the query are viewed in a cascading form view. Then
the
records that the user desires to be reported, (as not all records will be,
regardless of the depth of search criteria) can be selected and then when
the
user proceeds to a report only the selected records are reported.

I have made numerous posts, seeking guidance on this issue and have
received
no assistance. Do to the lack of interest and the timeliness of the
requirement I had a small play around myself and then gave up.

The problem than I found insurmountable is that I could not develop a
unique
checkbox for each record on the cascading form that can be referenced by
the
report. Even if this was possible my next challenge was going to be trying
to
link the unique check box to the record that is being displayed on the
cascading form and so that a link can be made by the report to that record
and then have that record displayed in a report.

The responses I received to previous posts essentially revolved around
generating a more accurate query to remove unwanted records being
returned.
This is a perfectly viable method if it wasn't that the basis for the
database is to make the finding of specific detail from brief/limited
detail
easier (I hope that makes sense). So to make the query even more specific
is
not desirable and creates unnecessary fields that no one will use.

Although I did get one that talked about adopting a sub-query but I feel
that
there must be an easier way.

So to have a way for the user to self filter the records return and decide
on
those that should be required in a report would seem very logical to me
and
why it is so hard remains a mystery.

Again I stress I don't know if this is even possible, if it is I may have
to
make the database available to users and provide an updated version down
the
track.

For any additional detail that I may not have included in this post please
refer to a previous post "Identifying records from a query to be reported"

If you know of a method of doing it or someone that has, I would
appreciate
some guidance.
Thanks for all your help you have really got me out of a sticky spot
thanks
again.


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...eries/200510/1