permissible characters

[Becky]

Newbie question: exactly which characters may be used in names of a) tables,
forms, reports,...? b) mdb file names?

TQ
Becky

 

[fredg]

Newbie question: exactly which characters may be used in names of a) tables,
forms, reports,...? b) mdb file names?

TQ
Becky

Access Help is your friend.
Name + Guidelines for naming fields, controls, and objects

Guidelines for naming fields, controls, and objects
Names of fields, controls, and objects in Microsoft Access:

Can be up to 64 characters long.
Can include any combination of letters, numbers, spaces, and special
characters except a period (.), an exclamation point (!), an accent
grave (`), and brackets ([ ]).
Can't begin with leading spaces.
Can't include control characters (ASCII values 0 through 31).
Can't include a double quotation mark (") in table, view, or stored
procedure names in a Microsoft Access project.
Although you can include spaces in field, control, and object names,
most examples in the Microsoft Access documentation show field and
control names without spaces because spaces in names can produce
naming conflicts in Microsoft Visual Basic for Applications in some
circumstances.

When you name a field, control, or object, it's a good idea to make
sure the name doesn't duplicate the name of a property or other
element used by Microsoft Access; otherwise, your database can produce
unexpected behavior in some circumstances. For example, if you refer
to the value of a field called Name in a table NameInfo using the
syntax NameInfo.Name, Microsoft Access displays the value of the
table's Name property rather than the value of the Name field.

Another way to avoid unexpected results is to always use the !
operator instead of the . (dot) operator to refer to the value of a
field, control, or object. For example, the following identifier
explicitly refers to the value of the Name field rather than the Name
property:

[NameInfo]![Name]

 

[John W. Vinson]

Newbie question: exactly which characters may be used in names of a) tables,
forms, reports,...? b) mdb file names?

TQ
Becky

From the Help file "Guidelines for naming objects":

Names of fields, controls (control: A graphical user interface object, such as
a text box, check box, scroll bar, or command button, that lets users control
the program. You use controls to display data or choices, perform an action,
or make the user interface easier to read.), and objects in Microsoft Access:

Can be up to 64 characters long.
Can include any combination of letters, numbers, spaces, and special
characters except a period (.), an exclamation point (!), an accent grave (`),
and brackets ([ ]).
Can't begin with leading spaces.
Can't include control characters (ASCII values 0 through 31).
Can't include a double quotation mark (") in table, view, or stored procedure
(stored procedure: A precompiled collection of SQL statements and optional
control-of-flow statements that is stored under a name and processed as a
unit. The collection is stored in an SQL database and can be run with one call
from an application.) names in a Microsoft Access project (Microsoft Access
project: An Access file that connects to a Microsoft SQL Server database and
is used to create client/server applications. A project file doesn't contain
any data or data-definition-based objects such as tables and views.).
Although you can include spaces in field, control, and object names, most
examples in the Microsoft Access documentation show field and control names
without spaces because spaces in names can produce naming conflicts in
Microsoft Visual Basic for Applications (Visual Basic for Applications (VBA):
A macro-language version of Microsoft Visual Basic that is used to program
Windows applications and is included with several Microsoft applications.) in
some circumstances.


However, I've seen really strange errors if punctuation such as commas,
hyphens, plus signs are included. It would appear that they're accepted but
they can cause trouble.

A lot of experienced developers restrict object names to letters (upper or
lower case or a mix), digits, and underscores and nothing else; in particular,
though you can use blanks in names, they can cause trouble if you ever need to
upsize to SQL/Server, and will require that you always, consistently, reliably
enclose your object names in [square brackets].

 

[Becky]

thanks fredg & John for the sound advice! Becky

Newbie question: exactly which characters may be used in names of a) tables,
forms, reports,...? b) mdb file names?

TQ
Becky

Access Help is your friend.
Name + Guidelines for naming fields, controls, and objects

Guidelines for naming fields, controls, and objects
Names of fields, controls, and objects in Microsoft Access:

Can be up to 64 characters long.
Can include any combination of letters, numbers, spaces, and special
characters except a period (.), an exclamation point (!), an accent
grave (`), and brackets ([ ]).
Can't begin with leading spaces.
Can't include control characters (ASCII values 0 through 31).
Can't include a double quotation mark (") in table, view, or stored
procedure names in a Microsoft Access project.
Although you can include spaces in field, control, and object names,
most examples in the Microsoft Access documentation show field and
control names without spaces because spaces in names can produce
naming conflicts in Microsoft Visual Basic for Applications in some
circumstances.

When you name a field, control, or object, it's a good idea to make
sure the name doesn't duplicate the name of a property or other
element used by Microsoft Access; otherwise, your database can produce
unexpected behavior in some circumstances. For example, if you refer
to the value of a field called Name in a table NameInfo using the
syntax NameInfo.Name, Microsoft Access displays the value of the
table's Name property rather than the value of the Name field.

Another way to avoid unexpected results is to always use the !
operator instead of the . (dot) operator to refer to the value of a
field, control, or object. For example, the following identifier
explicitly refers to the value of the Name field rather than the Name
property:

[NameInfo]![Name]

--
Fred
Please respond only to this newsgroup.
I do not reply to personal e-mail
.