But if you don't remember what the object is named but you DO
prefix queries with "qry" you STILL have to choose from amongst
all of the objects so prefixed. How do you do that unless you
already know what you are looking for? Do you just pick the one
that seems to jog your memory?
Well, I don't name then qry1, qry2, qry3, etc.
After qry, the name is just the same as the rest of you might use,
so the list presents itself in alphabetical order.
Seems to me that one should figure out exactly which object they
need (to the point of examining its design) before they go picking
it from some list.
Yes, and if all of your queries are prefaced with qry, they will
sort by name.
But, again, you need to distinguish somehow between tables and
queries that have similar names. My example was in a secured
application where you'd have tblPerson, which is secured, and
qryPerson which is simply "SELECT tblPerson.* FROM tblPerson WITH
OWNERACCESS OPTION". You'd definitely want to use the query in all
your user interface objects, though in many contexts you might very
well still use the underlying table, depending on your security
setup. If you completely lock the user out of even read-only access
to the underlying table, you would always use qryPerson.
In conversion situations, where I have to support some things for
backward compatibility, but want to build on a solid situation, I've
even taken existing tables and written queries that I name
"tblWhatever," because I know that someday, the tables used to
create the query named "tblWhatever" will eventually be replaced by
an actual table (at which time the query that impersonates a table
will be deleted.
In tables, the prefixes allow me to segregate tables by function
(the two most common I use are tbl and tmp), and I always know what
I'm looking for. I don't segregate query types at all, though.