ACC: Using "Name" in Expressions

Last reviewed: April 2, 1997
Article ID: Q112130

The information in this article applies to:

Microsoft Access versions 1.0, 1.1, 2.0

SUMMARY

Moderate: Requires basic macro, coding, and interoperability skills.

All Microsoft Access version 2.0 objects have a Name property, but Microsoft Access version 1.x objects do not. A Microsoft Access 1.x database does not run correctly in Microsoft Access 2.0 if you refer to Name as an ambiguously qualified object in the 1.x database. To correct this, Microsoft Access treats Name as a special case when you are using a 1.x database.

MORE INFORMATION

With the advent of Microsoft Access 2.0 and data access objects (DAO), all objects have a Name property. Name is also a very common field name. This creates a conflict when you are running a 1.x database in Microsoft Access 2.0. When you refer to an ambiguously qualified object, both Microsoft Access 1.x and 2.0 have a predetermined search path to locate the object. The search order is as follows:

   Properties, controls, fields

If a field has the same name as a property, the value of the property is returned instead of the value of the field. In order to deal with the new Name property, the search order when referring to Name changes to:

   Controls, fields, properties

Note that this only applies to Name and not to any other property.

Listed below is acceptable ambiguous syntax in Microsoft Access 1.x and unambiguous syntax in Microsoft Access versions 1.x and 2.0. Microsoft Access 2.0 handles the ambiguous syntax correctly when you are using an Access 1.x database.

Acceptable (Ambiguous) 1.x Syntax

In a text box on a report:
```
      ControlSource: =[Name]
```

In a macro:

      SetValue
         Item: [Name]
         Expression: UCase([Name])

In a DLookup() expression:

      DLookup("[ID]","MyTable","[Name]=Form.Name")

In Access Basic using ListTables(), ListFields(), and so on:

      Set MySnap = MyDB.ListTables()
      Debug.Print MySnap.Name

Unambiguous 1.x and 2.0 Syntax

In a text box on a report:
```
      ControlSource: =Report![Name]
```

In a macro:

      SetValue
         Item: Form![Name]
         Expression: UCase(Form![Name])

In a DLookup() expression:

      DLookup("[ID]","MyTable","[Name]=Form!Name")

In Access Basic using ListTables(), ListFields(), and so on:

      Set MySnap = MyDB.ListTables()
      Debug.Print MySnap!Name

Note the explicit use of the form or report object and the use of the exclamation point (!) instead of the period (.) to refer to fields. This tells Microsoft Access to search controls and fields and to ignore properties. If you use the period (.), properties are assumed and searched before controls and fields.

Using Naming Conventions

Ambiguously referenced objects can also be correctly referenced by using a naming convention that includes a standard prefix or suffix that can be attached to object names. For example, ctlName could indicate a control, and fldName could indicate a field.

Converting to Microsoft Access 2.0

When you are converting a Microsoft Access 1.x database to 2.0 format, you must use the unambiguous method to reference fields and controls that have the same names as properties.

REFERENCES

For more information about identifiers in expressions, search for "identifiers in expressions" using the Microsoft Access 2.0 Help menu.

Additional query words: dao
Keywords : ExrOthr kbusage
Version : 1.0 1.1 2.0
Platform : WINDOWS
Hardware : X86
Issue type : kbinfo

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: April 2, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.