Acc2003 object naming references are stricter than Acc2000?

  • Thread starter Thread starter WW
  • Start date Start date
W

WW

Well, I upgraded everything from Office 2000 to Office
2003. Now I have a major problem. Access 2000 never cared
if you refer to an object as
-----------------------
[Forms]![frmExplorer]![sbfrmGeneric]![cbo_Search]
-----------------------

or as

-----------------------
[Forms]![frmExplorer]![sbfrmGeneric].[Form]![cbo_Search]
-----------------------

but Access 2003 (with 2002-2003 file format) does - and
now my 60 Mb front-end application has forms w/ subforms
that no longer function because of this. (Access 2003
requires the extra << .[Form]! >> in the reference?)

The amount of code that I would have to sift through to
fix this is enormous. Queries, forms, subforms, reports,
and modules could all have these inadequate references. If
no one has a solution - I will have to go back to Access
2000.

Thanks for any advice.
-WW
 
Either of the methods you are using is bad practice anyway....neither will
catch errors during compile. Any of the following would be better
(depending on need):

Me.SomeControl

Or

Me.Parent.SomeControl

Or

Me.SomeSubForm.Form.SomeControl

Or

Forms("SomeForm").SomeControl

The only time I use the [Forms]![frmExplorer]![sbfrmGeneric]![cbo_Search]
syntax is in queries.
 
Well, I upgraded everything from Office 2000 to Office
2003. Now I have a major problem. Access 2000 never cared
if you refer to an object as
-----------------------
[Forms]![frmExplorer]![sbfrmGeneric]![cbo_Search]
-----------------------

or as

-----------------------
[Forms]![frmExplorer]![sbfrmGeneric].[Form]![cbo_Search]
-----------------------

but Access 2003 (with 2002-2003 file format) does - and
now my 60 Mb front-end application has forms w/ subforms
that no longer function because of this. (Access 2003
requires the extra << .[Form]! >> in the reference?)

The amount of code that I would have to sift through to
fix this is enormous. Queries, forms, subforms, reports,
and modules could all have these inadequate references. If
no one has a solution - I will have to go back to Access
2000.

Thanks for any advice.
-WW
Click to expand...

Hi WW,

This is a known issue that is being investigated. I don't believe this
problem affects your modules, so that's one less place you'd have to
consider making changes. You should be able to test to verify if modules
are affected by this.

If you own the Access 2003 Developer Extensions, you can use the property
scanner to examine all the properties in your database for something like
"Forms!". While this won't make the changes for you, at least it will give
you a list of all the location where this syntax is used and make it much
easier to make the changes.

Another way to workaround this issue, though it is not suggested, is to
turn off the Jet sandbox mode. I believe there is value in blocking
expression such as Kill and others that give hackers access to your file
system, which is why I don't recomend turning Sandbox off. I think there is
also a benefit in using the fully quaified .Form reference to make your
code more readable and managable. By using this syntax, there will never be
any doubt when others read your code/expressions that you are working with
the Form object of a Subform control. Just my $ 0.02.

--
Regards,
Mike Wachal
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Paul Overway said:
Either of the methods you are using is bad practice anyway....neither
will catch errors during compile. Any of the following would be
better (depending on need):

Me.SomeControl

Or

Me.Parent.SomeControl

Or

Me.SomeSubForm.Form.SomeControl

Or

Forms("SomeForm").SomeControl

The only time I use the
[Forms]![frmExplorer]![sbfrmGeneric]![cbo_Search] syntax is in
queries.
Click to expand...

I'd say it is a matter of opinion whether it is bad practice or not, and
there are arguments to be made on either side -- though in fact I also
prefer to use the dot notation as Paul Overway recommends. Note,
though, that there are circumstances in which one *must* use the bang
notation. Specifically, if one needs to refer to a control or field
that has the same name as a property of the form (not a good idea, but
it happens), then the bang must be used.
 
Back
Top