Crash To Desktop Issue

[systemx]

Hi all,

Today some of my users (primarily Access 9 users from what I can tell) have started experiencing weird Crash to Desktop issues.

The issue occurs when the user clicks a command button, which in turn should open an unbound form.

All other database functionality is working correctly.

The form is unbound, contains a combo, command button, listbox based on a query and several textboxes.

On open code is -

Private Sub Form_Load()

Me.cboType.Value = "Mail"
Me.lstResults.RowSource = "SELECT qryViewMail.ID, qryViewMail.Date_Received, qryViewMail.Customer_Name, qryViewMail.MDL_MVL, qryViewMail.Category, qryViewMail.Type FROM qryViewMail ORDER BY [ID];"
Me.lblStatus.Visible = False

End Sub

This functionality has worked correctly up until now.

Has anyone experienced similar issues before?

Thanks,

Rob

 

[WayneRyan]

Rob,

I don't know what you mean by "Crash to Desktop issues".

The code doesn't appear to have anything obviously wrong with it.
Have you stepped through the Form_Load code with the Debugger?
Does it really die within those three lines of code?

Is it a split DB? Do all user's have their own front-end?

Need more info ...
Wayne

 

[systemx]

Hi Wayne and all,

Sorry about that - was a bit of a panicked post when searching the forum did'nt give me the answer I needed. The issue still remains unresolved.

The DB is a split F/E writing to B/E x2. F/E is stored locally, B/E on a networked drive.

Basically, when some users click on a command button, Access crashes to the users desktop - no error message, nothing.

The code behind the button is simply DoCmd.Open "frmMyForm". I posted the form load code as a just in case....I don't think it has anything to do with my code.

The users who are having problems are on Access 9 - the application was developed in Access 2003 (but as an A2K DB). I am still rolling out so may be able to determine if it just an Access 9 issue.

I have not tested it with Debugger...did not even think to use this.

Basically..any advice would be appreciated

Regards,

Rob

 

[The_Doc_Man]

First thought: When you build a DB in a given version of Access, it implies use of certain library functions. However, there is absolutely no guarantee that MS, in its infinite wisdom (????????), won't change a DLL file on you and not bother to tell you about it. Upgrading versions of Access is a prime example of where something like this might happen.

I would check for references in the context of each user. Remember (if you didn't know this) that references are a Windows Registry function - so every user has a potentially different set of references.

When we switched from AC97 to AC2K, one of the gotchas was that some of the DAO libraries changed. So if we used a DAO routine in AC97, it wouldn't work in AC2K until we fixed the appropriate references. Therefore I would bet that you got bit by a similar bug, possibly different file name but same concept. You will have to fix this problem on all machines, unfortunately, because it is a registry key. It is somewhere in the HKEY_LOCAL_USERS hive (or in HKEY_CURRENT_USER). I can never remember exactly where. And besides, use the Access references interface to fix it. It's easier.

 

[systemx]

Hi & thanks The_Doc_Man,

I believe you are pretty much spot on.

I have two sets of users - Access 9 and Access 11. I am also using the Outlook Reference - so unload references (& missing) at startup, then reload the correct reference depending on which access version.

I now realise that those that are experiencing this problem are Access V9 users, with Outlook 2003.

Pretty sure that is the problem so should be able to work around it now. Will test it later today when I have a free moment! Failing that - I will arrange for them to be upgraded to Access 11.

Thanks again,

Rob