Re: SQL too long?

Good morning, guys,

and thanks for replying. While I haven't tried aliasing yet, I just want to
give you a snapshot of the status. The query/report worked several times this
morning, and in fact took an additional minor change without crashing. Now,
however, as I'm in the process of modifying the sister query (see my comment
to John below), Access keeps crashing again.

By the way, the denominators can't be 0, Gary, although good thought, because
if a denominator was 0 there would be no data at all for that invno, not even
a blank line. The lowest possible denominator is 1.

As to what 'ape-s---' means, I should have been more explicit. I got the
"Sorry for the inconvenience but Access has got to close..." screen. About 15
iterations of message, reopening the db, opening the query, message, ad
amnauseum. Even after I created a new object and imported all the objects and
worked on the NEW db I still got the same message. By the way, Gary, what's
PMFBI and WAG?

Also, John, because of the complexity of the query, I originally made it a
named query so as not to load down the report. In fact I have two parallel
queries, and depending on the OpenArgs argument of the OpenReport statement,
I assign either of these two queries as the report's record source.

By the way, Doug, I have a question about aliasing. Can I do aliasing in
Access's query design interface? That is, will Access save the query with the
aliases, or will it rename them as the original table names as part of the
'Save' operation? Also, will the saving of about 200 bytes appreciably alter
the stability of the query?

Thanks again,

Sam

Gary Walter wrote:
PMFBI

In addition to the previous sage advice,
you might expand on what "ape-s---" means.

It appears to me that you are doing a lot of
division w/o checking for 0 in denominator.

Since joins are all inner joins, is it possible
that some of those denominator counts could
be zero after joining new table?

A quick test might be to join all the tables
in a new test query and see what counts you
are getting.

Or, bite the bullet and preface all your divisions with
test for 0 in your original query (always a good idea
anyway).

Apologies for butting in (especially with such a WAG),

gary

I have a query with a long SQL statement. It was working all along, but
today
[quoted text clipped - 41 lines]
(Not [adjustment]) Or ([tblARMst01].[fob] Like "NEXT DAY*")))=False))
ORDER BY tblDUPSFreight.invno;

--
Sam

Message posted via http://www.accessmonster.com
.