Run-time error 2467... Oh yes it does!

[Guest]

I have a subform embedded into a main form. Strangely enough, the mainform/
subform functions normally when I run on my machine but when run on another
machine I get a "Run-time error 2467: The expression you entered refers to
an object that is closed or doesn't exist."

But this is simply not true. The object does exist. It is not closed. The
line of code that fails is the following:
If Not Forms!PurchaseOrders!sfmPoSingleLineItem.Form.AllowEdits =
PermissionItemUpdate Then
Forms!PurchaseOrders!sfmPoSingleLineItem.Form.AllowEdits =
PermissionItemUpdate

The form names are correct, PermissionItemUpdate is defined as Boolean with
a valid T/F status based upon the user’s capabilities. I started with a fresh
“shell†and imported everything in new to eliminate, to an extent, any form
corruption issue. Both machines are running Acc 2003 SP2.

Again it runs fine on one and blows on the other!

I am out of ideas. Any suggestions?

 

[Allen Browne]

References issue? (Tools | References from a code window.)

If not, make sure the Name AutoCorrect boxes are unchecked:
Tools | Options | General

Naturally, make sure the code compiles (Compile on Debug menu.)

Then start asking Access to identify what's wrong on that machine. Add code
such as:
Debug.Print Forms!PurchaseOrders.Name

If that works, try:
Debug.Print (Forms!PurchaseOrders.sfmPoSingleLineItem.ControlType =
acSubform)

And then:
Debug.Print Forms!PurchaseOrders!sfmPoSingleLineItem.Form.AllowEdits

Followed by:
Debug.Print (Forms!PurchaseOrders!sfmPoSingleLineItem.Form.AllowEdits =
PermissionItemUpdate)

 

[Guest]

Thanks Allen,

I had already checked the references and the code compile. No issues there.
I had forgotten the Auto Correct issue as it is always turned off on my
machine. I'll check that and I then will try your debug suggestions.

It certainly has my head scratching! I'let you know what I find out.

Always good to talk to an Aussie!

Rick

 

[Guest]

References issue? (Tools | References from a code window.)

If not, make sure the Name AutoCorrect boxes are unchecked:
Tools | Options | General

Naturally, make sure the code compiles (Compile on Debug menu.)

Then start asking Access to identify what's wrong on that machine. Add code
such as:
Debug.Print Forms!PurchaseOrders.Name

If that works, try:
Debug.Print (Forms!PurchaseOrders.sfmPoSingleLineItem.ControlType =
acSubform)

And then:
Debug.Print Forms!PurchaseOrders!sfmPoSingleLineItem.Form.AllowEdits

Followed by:
Debug.Print (Forms!PurchaseOrders!sfmPoSingleLineItem.Form.AllowEdits =
PermissionItemUpdate)

Hi Allen,

The problem still exists but its now a bit stranger than I first relaized.
The file in question is an ADP file, so I converted to an ADE to see if that
made a difference. And it ran fine!

I went back to the original ADP file and plugged in the debug.print
statements you suggested, in the same order you suggested them, and it blew
up with the same 2467 error :

The first 2 worked fine

Debug.Print Forms!PurchaseOrders.Name
Debug.Print (Forms!PurchaseOrders.sfmPoSingleLineItem.ControlType =
acSubform)

This following is the line that blew up:

Debug.Print Forms!PurchaseOrders!sfmPoSingleLineItem.Form.AllowEdits

I am lost for any explanantion. The machine that this is running on is a
new desktop and all other apps are running without a problem. Why would
converting it to ADE file make the problem go away? Memory error?

Any thoughts at all?

Thanks,
Rick

 

[Allen Browne]

Okay, so you have confirmed that the object is a subform control. The next
step would be to ask for the SourceObject of the subform control:
Debug.Print Forms!PurchaseOrders.sfmPoSingleLineItem.SourceObject

If there were no object in the subform control, then you could refer to it
but the .Form would fail.

Given that the reference worked in an ADE, it may be the kind of corruption
that a decompile would fix:

1. Double-check that those Name AutoCorrupt boxes are unchecked.

2.Compact.

3. Make a backup copy of the file.

4. Decompile by entering something like this at the command prompt while
Access is not running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.adp"

 

[Guest]

For those who visit this thread I finally found the answer!

Over the weekend I sat down side by side, my laptop and the desktop. I
compared everything I could think of at the Access level. Worked on my
laptop and didn’t work on the desktop. Each was using their own server so I
decide to connect my laptop to the same server that the desktop was
connected to. And viola it failed!

In my case in turned out to be permissions in the SQL Server database I was
connecting to. Even this didn’t make sense to me. I was getting a VB object
does not exist error in referencing a subform property???? Then it occurred
to that it was the defined view (recordset) of that subform that was having
the security issue. Hence no record associated with the form. Hence no
valid allowedit property. I could not prove it but once the SQL Server
permissions security was addressed everything worked fine.

On both the laptop and the desktop.

Gotta love computers!!!

Allen, thanks again for your help and support.

 

[Guest]

Rick and Others,

I have a similar problem!!! I am using a Access 2000 Front end Back End
configuration and get the same error when I try to input data to a control on
my subform. I know the control exists on the subform, but debug shows that
it breaks when I try to put a value in that control. I tried all the things
in your threads to no avail!!! Anyone out there have any additional ideas?

(If I create a new form/subform combination in the db with some of the same
controls discussed, it works fine. This particular form/subform combination
is busted!!)