Believe it not, pre-compiled queries are not always faster in terms of
performance.
If that query has got any parameters, then building the sql string is
actually faster.

The problem is that query compile time is very small.

When you use in-line sql, you FORCE the query optimizer to re-compile. This
actually means that the JET engine often does a BETTER job when you force a
re-compile each time.

I have experienced this in-line speed advantage over querydefs with
parameters, and to quote from the JET white paper page 18, we get:

<quote>

Check Parameterized Queries for Optimal Performance

Parameterized queries can only be implemented by using a stored query. Since
stored queries have a precompiled query plan, parameterized queries that
contain parameters on indexed columns may not execute efficiently. Since the
query engine does not know the values to be passed in a parameter in
advance, it can only guess as to the most efficient query plan.  Based on
customer performance scenarios that we have examined, we have discovered
that in some instances substantial performance gains can be achieved by
replacing a stored parameterized query with a temporary query. This means
creating the SQL string in code and passing it to the DAO OpenRecordset or
Execute methods of the Database object.

</quote>

Note the word "substantial performance gains", and I seen the above many
times...

It is important to point out that use of quires is generally preferred since
to go on a wild goose hunt everytime to change some sql in code is rather a
maintains nightmare. If  you can put the sql in saved quires, then you
should.

Of course, I like as you mentioned, you use a mix of both, and that is
really the answer.