Hi, Dave.
You're welcome.
If some representative from Micro$oft is reading this
You've posted this message on UseNet, a voluntary peer-to-peer forum,
available to the public worldwide, so there's no guarantee that an employee
from any particular company in any particular country will ever see this
message.
I would like to have an explanation for what follows.
If you want answers from Microsoft, then Microsoft's E-mail tech support
costs $99 per incident, and phone tech support costs $245 per incident.
Please see the following Web page for contact information:
http://support.microsoft.com/oas/default.aspx?ln=en-us&x=11&y=12&prid=6689&gprid=36052
Another way that you "might" get an answer from Microsoft is to pay for a
TechNet subscription and then submit a question through TechNet. Your
question will still get routed to UseNet where anyone in the world can
respond to your question. If no one responds to your question within two
business days, then Microsoft tech support will respond.
However, there's no guarantee of a correct answer when posting a question on
UseNet. If you want guaranteed answers or solutions, then hire a company or
consultant that offers tech support or hire Microsoft's tech support.
You're in luck with these Access newsgroups, though, because a lot of
experts answer questions here. You'll usually receive at least one correct
answer to your question, but remember that paying customers get personalized
service, and they usually get the best service, as well.
If it has been my ignorance, you have my appology in advance.
No apologies necessary. We've all been in your shoes (or will be), and just
need a little help now and then to get where we want to go.
How should I have known that or been reasonably expected to have found the
information in M$ documentation and Help files?
Object names, such as table names and field names are "identifiers,"
commonly called "variables" by programmers. Naming of variables is covered
under "Guidelines for naming Visual Basic procedures, variables, and
constants" in Access's online Help section. Further restrictions for the
number of characters in table names and field names and restrictions for
queries are covered under "Access Specifications." Since you are using SQL
in the VBA code, "SQL Reserved Words" in online Help lists variable names to
avoid within your SQL code, as well.
You can also learn this information from Access "how-to" books or beginner
programming courses. Please see Jeff Conrad's (Access MVP and The Access
Junkie) Web page for links to commonly recommended books:
http://home.bendbroadband.com/conradsystems/accessjunkie/resources.html#Books
The reference sent below by '69 Camaro doesn't seem to refer to table
names.
Okay. So I'm a mind reader in training. After I graduate, I'll be making
$300 an hour, so you got a bargain. ;-)
Why isn't Access smart enough to recognize the reserved word in the table
name and bracket it?
Because this "feature" would cripple very useful functionality that we
currently enjoy. And it's not Access that handles SQL. It's the Jet
Expression Service that's handling the SQL you wrote -- which can become a
very important distinction for Jet 4.0 security restrictions that manifest
as obstacles (for your computer's "safety") in Access 2002 and 2003. That
SQL is a string that must be parsed according to syntax rules (to govern
what commands are allowable), and then the commands are passed to the
database engine, which applies the relationships, constraints, triggers, et
cetera, when retrieving the data set described by your SQL statement.
The Jet Expression Service must catch all mistakes in the syntax that would
cause the database engine to choke (or run endlessly) in order to prevent
such an ill-formed query from running. Allowing the Jet Expression Service
to automatically fix incorrect syntax by enclosing brackets around keywords
and reserved words that are not being used for their intended purposes would
result in too many mistakes (i.e., identifying a "choke" expression when it
shouldn't) and take an extremely long time to iterate through all of the
possible allowable combinations while parsing the SQL string into database
engine commands. It would also interfere with the Jet Expression Service's
current use of brackets around subqueries and table aliases, so those could
not be allowed in SQL statements. This alone would severely limit the
functionality of the relational database engine.
Is it too much to expect that a reasonably intelligent person should not
have to lose valuable productivity to crap such as this?
"Reasonably intelligent" isn't an appropriate benchmark for your
expectations of how Access's functionalities work. Anyone who knows their
way around a computer and can find UseNet to post a question is more than
reasonably intelligent. The appropriate benchmark is "experienced
developer."
Experienced developers avoid wasting valuable time by avoiding "built-in"
bugs, so that when they're writing code, they get it right the first time --
every time.
Have you ever written a query, then tried to run it only to receive a syntax
error, but fixed it by placing brackets around the field name, table name,
or query name? That table name, field name or query name is a built-in bug.
Change it to another name that you will never trip over. Access allows one
to create these names using reserved words or names that include spaces or
special characters, but that doesn't mean that one should do so. These
particular built-in bugs become show stoppers if the database is ever
migrated to another database engine, because those other database engines
weren't designed to be used by untrained users. They aren't very
user-friendly, like Access is.
Look at the directories and file names on your computer. See any
directories or file names with embedded spaces or special characters? What
are the chances you (or someone using your computer) will forget to enclose
that non-standard path name or file name within a pair of double quotes when
typing the command to open, save, send, et cetera, it in some application or
shortcut? Built-in bug. What are the chances you (or someone using your
computer) will try to use a path name or file name with an embedded period
(or which includes an IP address) as a data source in Office XP
applications? Built-in bug. Windows allows one to create non-standard path
names and file names, but that doesn't mean that one should do so.
Got directory names or file names that use the Windows long name convention,
instead of the old DOS 8.3 convention? S-s-l-l-o-o-o-o-w-w. Especially so
if the data source is far down the directory tree from the root directory.
(Gotta run the Windows API function for long names, as well as the Windows
Networking API functions for checking Windows User permissions for every
directory in the tree.)
Experienced developers also avoid using coding conventions that cause
unintended side effects. Declaring variables implicitly instead of
explicitly defaults to the Variant data type, which can lead to unintended
side effects. Your code below has six variables declared implicitly as
Variants. Using the Stop statement can have unintended side effects. (Use
a breakpoint, instead.) Passing parameters by reference instead of by value
or allowing Access to "fix" poor programming habits (such as automatically
adding brackets around an identifier) can lead to unintended side effects,
too. These are all examples of bugs that are just waiting to happen.
For more Access tips, please see the following Web page:
http://www.Access.QBuilt.com/html/gem_tips.html
HTH.
Gunny
See
http://www.QBuilt.com for all your database needs.
See
http://www.Access.QBuilt.com for Microsoft Access tips.
(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
Beware to those who use munged addresses: known newsgroup E-mail harvesters
for spammers are (e-mail address removed) and (e-mail address removed)
