Another runtime error in Access 2010

[Leif]

I've gotten a new error in Access 2010 runtime. I'm trying to convert from Access 2003 to 2010. For Access 2003 everyone has a development copy. In the move to 2010 they decided to save some money and only provide the runtime for most users. I'm keeping the database as an MDB. Perhaps I would do better to give that up?

The error I'm getting is:

"Microsoft Access has stopped working

Windows can try to recover your information and restart the program.

(button) Restart the program"

The error occurs when I try to open a form via VBA coding in a different form.

A button is clicked executing the following code:

Private Sub cmdJumptoMOC_Click()
    ' Jump to the MOC form
    
    ' If the form is already open then close it first
    If isFormOpen("MOC") Then DoCmd.Close acForm, "MOC"
    
    ' Bring up MOC form
    DoCmd.OpenForm "MOC", , , , , , "MOCID=" & MOCAllDocsSF!MOCID
End Sub

MOCID is an integer value that represent the primary key of the MOC form.

The MOC form has a form and subform. I've traced it though the event procedures. I get the error after the open and current events. In the open event I have the coding:

Private Sub Form_Open(Cancel As Integer)
    ' If open with an argument then jump to the record.  However, turn off add rights
    If Parent.OpenArgs <> "" Then
        Filter = Parent.OpenArgs
        FilterOn = True
        AllowAdditions = False
    End If
    
    ' Set security
    FormSecurity Me
End Sub

My work around is to use the FindFirst method instead of a filter. That seems to work without an error. It is the following:

Private Sub Form_Open(Cancel As Integer)
    ' If open with an argument then jump to the record.  However, turn off add rights
    If Parent.OpenArgs <> "" Then
        Me.Recordset.FindFirst Parent.OpenArgs
'        Filter = Parent.OpenArgs
'        FilterOn = True
'        AllowAdditions = False
    End If
    
    ' Set security
    FormSecurity Me
End Sub

The FormSecurity function sets the passed form object (field) locked status depending on the user and the content of the object tag property. That is partly how I implement security. However, I think that is not the issue. It is the difference between using a filter and using FindFirst.

This original coding works just fine in 2003 developement version (did not test 2003 runtime). However, fails in 2010 without the work around.

I know there is much going on VBA wise, but I was wondering if anyone may have an idea of what is going on the runtime?

 

[spikepl]

You have not implemented an error handler that might tell you what is going on, but persist in flying blind. For the last time: implement an error handler in each of your routines. If you do not know how then say so.

 

[Leif]

You have not implemented an error handler that might tell you what is going on, but persist in flying blind. For the last time: implement an error handler in each of your routines. If you do not know how then say so.

I do appreciate the help. I don't appreciate the tone.

I've added a On Error Goto as follows:

Private Sub Form_Open(Cancel As Integer)
    ' If open with an argument then jump to the record.  However, turn off add rights
    On Error GoTo OpenErr
    If Parent.OpenArgs <> "" Then
'        Me.Recordset.FindFirst Parent.OpenArgs
        Filter = Parent.OpenArgs
        FilterOn = True
        AllowAdditions = False
    End If
    
    ' Set security
    FormSecurity Me
    Exit Sub
    
OpenErr:
    MsgBox "Error Form Open " & Err.Description
End Sub

I also added the following form error handler.

Private Sub Form_Error(DataErr As Integer, Response As Integer)
    MsgBox "Error in form MOCSF.  DataErr=" & DataErr
End Sub

Same thing. No message box. Just get the error

Microsoft Access has stopped working

However, if I remove the comment on the above FindFirst, and comment out the next 3 lines (Filter, FilterOn, and AllowAdditions), it works. And also, I as mentioned, it works fine with Access 2003 development copy without the FindFirst (using a filter).

 

[JHB]

I don't think it make any change, but I would use Me in front of Parent.

Me.Parent

 

[Galaxiom]

Given this is the second runtime code problem from the OP maybe we should be looking at the Runtime installs?

I assume you have definitely isolated the differences to runtime and full Access by trying on a few machines of each type.

What versions of operating systems are involved?

I had a seriously weird problem with Excel when we went to Office 2010. It went away eventually.

 

[Mihail]

Verify if the OpenArgs are passed (and used) correctly.
I have had a ton of troubles before to understand that, somehow, the OpenArgs are lose.
So, in each form that use OpenArgs, I do this:

Option Compare
Option Explicit

Dim OpArg 'So, visible in this module

Private Sub Form_Load
OpArg = Me.OpenArgs
.....
End sub

Then I use the OpArg variable in my code, instead the OpenArgs.

Also, I don't understand this:
DoCmd.OpenForm "MOC", , , , , , "MOCID=" & MOCAllDocsSF!MOCID

You say:

MOCID is an integer value that represent the primary key of the MOC form.

I can't say that the syntax is wrong, but I can say that I don't see this before (to refer a variable with this syntax).
Can you, or someone else to make me understanding how this work ?
I think that should be Forms!FormName!ControlName .

 

[Galaxiom]

Then I use the OpArg variable in my code, instead the OpenArgs.

I have never found a need for this. Both are simply references to somewhere in the memory. AFAIK OpenArgs is no more volatile than a variable.

Also, I don't understand this:
DoCmd.OpenForm "MOC", , , , , , "MOCID=" & MOCAllDocsSF!MOCID

You say:


I can't say that the syntax is wrong, but I can say that I don't see this before (to refer a variable with this syntax).

Can you, or someone else to make me understanding how this work ?
I think that should be Forms!FormName!ControlName .

Once can of course refer to a control via the Forms collection. Then of course we often we refer to a control on the current context object with Me. I think this just should have the Me.

However I noticed that MOCAllDocsSF suggests it might be a subformcontrol. If so this particular syntax is not as widely known as what most developers use, having all found the common references here.

As shown in the link normally we refer to a control on a subform with:
Me.subformcontrolname.Form.controlname

However a control or field on a subform can also be referred to as:
Me.subformcontrolname!controlname

Note this is one of the few places where a bang (!) is required in Access syntax.

 

[Mihail]

@Galaxiom
Thank you very much for teaching me.

I have never found a need for this. Both are simply references to somewhere in the memory. AFAIK OpenArgs is no more volatile than a variable.

I encountered this many many times. It is why I decided to save the OpenArgs very early when I open a form.

Maybe my installation kit contain a bug ?! Because I used the same kit more times (after I kill my Windows with my own hands trying whatever cross my mind ) and the issue persist.

 

[Leif]

Yes, the reference MOCAllDocsSF!MOCID is to a subform. I have it arranged as a form with some combo boxes for search and some command buttons for opening other forms with related data. This is activated by one of the command buttons cmdJumptoMOC click event, which I guess is probably obvious.

DoCmd.OpenForm "MOC", , , , , , "MOCID=" & MOCAllDocsSF!MOCID

The main form has no recordset. The subform has the data. MOCAllDocsSF is the subform of the main form MOCAllDocs.

I usually only use the Forms object when referencing a form not part of the current form (where the code is being executed). For subforms I refers them with their name and either the control name or recordset field name. Or sometimes I need to go up then down, such as subforms A and B within a parent, for example parent.B.field from subform A.

I do have a work around, as I explained (using FindFirst). But I use the filter technique in other places, so I am concerned. From my limited experience with 2010 runtime it does not seem very robust. Code that works without issue in 2003 development is not working in the 2010 runtime. And when it encounters a problem it simply gives up. Perhaps I'm not doing enough error trapping, but that was not necessary in 2003, and the error trapping is not be trigger in any case (so far).

Regarding 2010, I've been provided a laptop and a desktop. One with the 2010 development and one with only the runtime. I really have no idea how this is being installed. Both of my computers are getting the errors. On the development machine I run with the /runtime switch.

 

[Leif]

It hard to say since my runtime errors are not consistent. But now I see an error on the desktop runtime machine that I do not see on the laptop development machine using /runtime.

I'm going to ask them to reinstall the Access runtime on the desktop machine.