yes, usually when you're writing code or using expressions or functions
anywhere in the database. it's very easy to confuse Access; for instance, it
may think that you're referring to an object's Name property when you intend
to refer to a field called "Name". if it isn't practical to fix this
particular database, just keep the issue in mind as a possible cause, if you
run into errors or unexpected results when you make additions or changes to
the db structure.
sometimes, you can "get around" a problem in a form or report by basing it
on a query, and renaming the troublesome field within the query. in code, i
believe you can force Access to recognize field names, if necessary, by
enclosing them in brackets [ ]. (i won't guarantee that'll work. i never use
reserved words as names, so i've no personal experience in compensating for
the problem.)
don't use those "fixes" as a patch for sloppy naming conventions in your own
databases, though - doing it right at the table level is much easier than
working around the problem!
hth
Paul said:
Thanks that work!
I kinda inherted this DB and there are a few things wrong with it. Can
naming a field "name" or "date" or any reserved name cause real problems?
tina said:
set the combo box's ColumnCount to 2, and the ColumnWidths to 0 for the
first column and as wide as you need for the second column - example:
ColumnWidths 0";1.5"
btw, i hope you don't really have a field in your table called "name".
"Name" is a reserved word in Access; you should not use Reserved words as
the names of tables, fields, or any other objects you build in your
database.
hth
Paul said:
Hi,
I'm having problems with this report. It has a combo box that is giving me
the autoId number instead of the name I want. the Row Source is set to
SELECT [agent name].[agentautoID], [agent name].[name] FROM [agent]
and the Bound colunm is 1
No matter what I try its giving me the number not the name. What should I
change this to?
