Error in 2010 runtime

[Leif]

I get the following error in the Access 2010 runtime using an mdb. I do not get the error in the Access 2010 full version using an mdb or the Access 2010 full version or runtime using accdb. The close command relates to the form executing an event procedure. It successfully closeds the window.

"Execution of this application has stopped due to a run-time error.

The application can't continue and will be shut down."

Since I'm in runtime I need to go back to the old way of locating an error.

Below is the coding.

MsgBox "About to close window"
DoCmd.Close
MsgBox "Window closed. About to Open database window"
ShowDbWindow
MsgBox "Showdbwindow executed"

It fails at ShowDbWindow. I don't see the final message. ShowDbWindow is:

Public Sub ShowDbWindow()
DoCmd.SelectObject acTable, , True
End Sub

 

[pbaldy]

I don't think you can access the Nav Pane in the runtime version.

 

[Leif]

I don't think you can access the Nav Pane in the runtime version.

Yes, your right. I thought I saw it working on a accmb file, but testing it again, it also generates the same error.

I'm also getting the message when moving from record 2 to record 3 on a different form (record 1 to 2 is okay). I have no missing references in VBA, having converted my Excel references to late binding in my mdb. Any other reasons I would get this error? I've not been able to trap with the form_error event handler.

 

[pbaldy]

Not offhand. How are you moving from record to record (navigation buttons, custom buttons, etc)? Is there code running in the current event? Or a function called in a textbox that would be running?

 

[Leif]

I'm using the record navigator. There is quite a bit of coding in the current event. The frustrating thing is it is not consistent. Sometimes I can move through multiple records, like 1-6 sequentially. Then I close the form and reopen it and when I move from record 2 to 3 I get the error. The last time I tried it was on the third open/close process that I got the error moving from record 2 to 3.

I guess the only way to debug this is to start populating the event with msgbox statements so I can see were it is tripping up. You do have a suggestion?

Thanks for your help.

 

[pbaldy]

It smells like something in the data causes the code to blow up (like a Null field). Does it happen in an mdb/accdb and the full version of Access? If so, are you not offered the opportunity to go into debug mode? Another option to the message boxes is to set a breakpoint and step through the code, though that works best when the error is consistent.

 

[spikepl]

I'd suggest that you put errorr handling in all your code, without exception. Download MZTOOLS and it can put handlers in automatically. That might give you a clue as to the error. Without this, the thing just dies in the runtime, with the error you have been receiving covering the entire error universe.

 

[Leif]

Paul,

No problem in the full version of Access. No offer to go to debug mode in runtime. Cannot trap with form_error.

Don't I need to use the full version to step through the code? It works fine in the full Access version.

spikepl,
Thanks for the tip on NZTOOLS. I'll give that a try.

 

[spikepl]

It is time consuming and painful

Quite - if you do it in Access. For this type of stuff I copy the code to Word and run a macro.

 

[Leif]

I have found that I had to insert some documenting code in a suspected module in order to find the problem when running in the runtime version. What I did was to add a line which writes to a log file for each step of the way, in advance so when it stops I look at the log and it shows me which step it just executed which would be the one it errored on.

Thanks Bob. That is certainly an improvement over using msgbox. Perhaps I can just use a variable that I increment on each statement to save me the work of copying the statement. I have over 100 lines.

 

[Leif]

Interesting.

In the runtime it is failing when it tries to evaluate the field owner.column(1), which is null. Owner is a bound value list combobox. The subform containing the combo is an integer value. I tried using nz, but it still failed.

Trace is a routine to write a numeric value to a file. TraceTxt write a string value to the same file (append). Without the Trace routines it fails on the if statment (Trace 33 does not execute). I put traces in the AQA and UQA routines and they were not executed.

Trace (32)
Tracetxt (CBool(gCDR))
Tracetxt (Nz(Owner.Column(1), "Null"))
Tracetxt (CBool(gAdmin))

' CDR cannot update hold date for QA. Changed per Rick on 5/11. Only CDR may update hold
If gCDR And Owner.Column(1) = "QA" And Not gAdmin And Not AQA(projID) And Not UQA(projID) Then
Trace (33)

 

[Leif]

You might need to be more specific in the code and add the explicit ME keyword.

If gCDR And Me.Owner.Column(1) = "QA" ...etc.

Also, have you made sure that the control source for Me.Owner has two columns and the column count property is set to 2 (or more if there are more)?

That is it! Wow, I would never have guessed! It works fine in the development version of Access, but fails (sometimes!) in the runtime. When I add "ME." is it not failing. I would have thought "me." would be the default, using late binding.

Thanks much for the suggestion.

What you think the rule is? Should I add "me." to all form object references? That would be a huge chore.

 

[Galaxiom]

Me should always be used for any reference to the object. Otherwise the program begins guessing. Usually it guesses correctly but you really don't want any guessing going on.

I have seen Access fall over when objects with the same names were present on other open forms and the Me was not included.

 

[Leif]

The bound control Owner has a value list as follows:
"1";"CDR";"2";"QA"

With a column count of 2. And column widths of 0", and List width of Auto. That suppresses the index value (1 or 2) and only shows blank, CDR, or QA.

I'm going to check for other column references in my database. Perhaps the runtime is particularly sensitive to those.

 

[Leif]

It is failing again. Even after I added the Me. It is failing at the same location. I've isolated it to the following statement. I get 33, but not 34 to my file. I'm getting "Null" for the third record, when it does not fail.

Trace (33)
Tracetxt (Nz(Me.Owner.Column(1), "Null"))
Trace (34)

Tracetxt is

Public Sub Tracetxt(txt As String)
   Dim strFile As String
   Dim iFile As Integer

    strFile = "C:\Temp\MyLog.txt"
    iFile = FreeFile
    Open strFile For Append As #iFile
    Print #iFile, "Reached text " & txt
    Close iFile
    
End Sub

It is definitely an Access runtime bug. Why do I say that? I have no problem with the development package. The error only appears in runtime. It varies, but sometimes I open the form go through record 1-4, no problem, then close the form. Then I open the form again, try to go through 1-4, but it fails on record 3. I'm the only one using this test database so no data change is involved.

So given it is an Access runtime bug, I'm wondering what is the work-around or how can I test further. This is very puzzling since after I added the Me. a couple of days ago it tested fine. Now, it seems I'm back to the beginning.

FYI, this is an MDB file. I am making changes (adding trace statements) in 2003 and testing in 2010 runtime. Works fine in 2003 development version.

 

[Galaxiom]

I put traces in the AQA and UQA routines and they were not executed.

If gCDR And Owner.Column(1) = "QA" And Not gAdmin And Not AQA(projID) And Not UQA(projID) Then
Trace (33)

It the functions didn't run then the execution never got to the line that called them.

You are posting the pieces of code you think are the problem but it looks to me like you are barking up the wrong tree.

 

[Leif]

Which functions? The trace and tracetxt functions? They do run. I do get output. The AQA and UQA functions? I do have traces in them as well. I think I have the right tree, which is the owner combo box. That would be why the Tracetxt (Nz(Me.Owner.Column(1), "Null")) fails. Not everytime, but when it does fail this is where it fails.

 

[Galaxiom]

Which functions? The AQA and UQA functions? I do have traces in them as well.

Yes. You said they didn't run.

I put traces in the AQA and UQA routines and they were not executed.

If they didn't run then the line that called them was never reached.

If gCDR And Owner.Column(1) = "QA" And Not gAdmin And Not [B]AQA(projID)[/B] And Not [B]UQA(projID)[/B] Then

Hence the Owner combo would not be relevant.

 

[spikepl]

Have you put in the error handler that might tell you what the thing gets upset about? If you have then what does it say? If not then flying blind but in circles is a bit pointless

 

[Leif]

Yes. You said they didn't run.

If they didn't run then the line that called them was never reached.

If gCDR And Owner.Column(1) = "QA" And Not gAdmin And Not [B]AQA(projID)[/B] And Not [B]UQA(projID)[/B] Then

Hence the Owner combo would not be relevant.

I don't know exactly, but I think the Owner.Column(1) was executed before it got a chance to execute the AQA and UQA functions.

Anyway, as you can see from my post at 10:17 AM today(post #18) I separated out the particular portion of the IF statement and put it inside my TraceTxt function:

Tracetxt (Nz(Me.Owner.Column(1), "Null"))

It failed to output the content of that column. That is the reference to the Owner combo box.