MsAccess random errors

Question

We are upgrading our desktops from Dell workstations on windows 7 with office 2003, to Intel NUC's, windows 10, running Office 2010.  For whatever reason both of the test deployment nuc's are causing issues.  Random issues.  

"The expression On Dbl Click you entered as the event property setting produced the following error: Reserved error (-1104); there is no message for this error."

That is the most frequent error.  Another one is '~sq_cfrm_akMainNavigator~sq_clist_Patients' is not a valid account name.

We have tried everything.  Removing all references that were nolonger needed.  Replaced the network cable.  This is the 3rd try on a 3rd NUC.  Three different model nuc's.  I7, I9, and Skull Canyon.  

Prior to this the user would get something along the lines of "Database has been disconnected"

The user runs an accde locally (Forms, Reports, Queries) which has linked tables to an accdb stored on a network share (Data tables).

On the last NUC I tried disabling SMB LanMan v2.  That just changed the errors slightly.  

The first error is one I would kind of expect if a reference was missing.  Say the Word.olb was missing, you would see random expression errors on click events.  But in this case all references are locally and exist (access, ado, qbsdk)

At this point we've ruled out Office 2010, as it works on all other users.  We ruled out hardware as this user is testing the 3rd NUC.  We mostly ruled out network issues by running a fresh cord from their desk right to our server room.  We upgraded from MDBs to ACCDBs.  We eliminted all network references.  We tried changing Linked Tables from \\server\share to \\192.168.1.X\share as a suggestion from google.  The only thing left is downgrading from Win10 to Win7 but I can't see how that is a problem.

A second user started to use a NUC and within 5 minutes received the same error.

Any ideas? Thoughts? Suggestions?

  -Ryan

---

-Ryan Pavely Net Access Corporation

Answer 1

Hi Ryan,

You said you have eliminated Office 2010 because it works for other users. Are you saying those other users are using the new NUCs?

Answer 2

Eliminated office 2010 as the rest of the staff, on their dells, have been upgraded from 2003 to 2010.  And the front-end DB converted to accdb.  I saw a new search suggesting -1104 was 'too many tables' open however access 2010 can have a huge number.  I wrote a routine to for-each-table close it.  Oddly when I did I started to get -1104 errors just the once but not again.

What makes this user test special is 1. NUC, 2. Win10.  The only other user on the same platform received the -1104 error yesterday once.

I myself am on a NUC, and win10, and office 2010.  I do not use the app as much as they do but I have yet to have the problem, ever, except when I ran the aforementioned close-all script.

---

-Ryan Pavely Net Access Corporation

Answer 3

Hi Ryan,

>>We are upgrading our desktops from Dell workstations on windows 7 with office 2003, to Intel NUC's, windows 10, running Office 2010.

Did this issue only exist on NUC?

Based on your description, it seems you could reproduce this issue on your NUC with this accde, am I right?

To identify whether it is related with environment or accde, I would suggest you create a simple accde and test it on NUC.

If you could not reproduce this issue in a simple Accde, I would suggest you add Forms, Reports, Queries from original accde part by part to check whether this issue will reproduce in a new Accde.

Please feel free to let us know your test result.

Best Regards,

Edward

---

MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [e-mail].

Answer 4

It took some driver mangling but I was able to get Windows 7 installed on two of our NUC's.

So far, MsAccess has had zero issues.

Therefore the common denominator is Windows 10.

What on earth is Windows 10 doing, to cause this -1104 error?

---

-Ryan Pavely Net Access Corporation

Answer 5

Hi SirParadox,

>> Therefore the common denominator is Windows 10

My environment is Windows 10 with Office 2010, and my Access 2010 works correctly. I am afraid the Windows 10 is not the root cause for your issue.

Could you reproduce your issue with a new simple Accde under Windows 10 with Office 2010?

Best Regards,

Edward

---

MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [e-mail].

Answer 6

We have continued to test.

 It took some doing but I was able to get Windows 7 loaded on the NUC's.  Zero -1104 errors, however the video drivers made that an impossible solution.

 Today I finally got a free, normal employee workstation, and installed windows 10.  Within 30 minutes of a user testing it they received -1104.

Therefore, across all tests.  Office 2003, 2010, 2013, 2016.  Win7, Win10.  The only common denominator is Windows 10.

We have gone through all the power saving modes.  Network sleep modes.  Advanced properties of the NIC.  I added VBA code to open all databases as a global static variable to 'wedge' it open.  Nothing corrects or lessons the occurrence of this problem.  

When the error occurs.  The user can continue to fetch new data.  e.g. you're on a main customer lookup.  You can lookup another user.  But then opening any additional form, or table directly, will give the -1104 error.

---

-Ryan Pavely Net Access Corporation

Answer 7

Here's a neat trick.  When the error pops.  Close the current database.  File -> new database

"The Microsoft Access database engine could not find the object 'MSysACEs'.  Make sure the object exists and that you spell its name and the path correctly.  If 'MSysACEs' is not a local object, check your network connection or contact the server administrator.

https://lh3.googleusercontent.com/-VzVcfgl7rRk/WUv9LOLLEkI/AAAAAAAAAZI/xMNQLJxtWI0l-QPoQ_I-poQsicjuN2rSACL0BGAYYCw/h114/2017-06-22.png

---

-Ryan Pavely Anderson-Kelly, Assoc.

Answer 8

Hi Ryan,

Could you reproduce this issue with a simple new Access database?

Per to this error message, it seems your Access database is broken. How did you follow “File -> new database”? In my option, if you close the access database, there is no option for File. If you create a new database with Access opening, I suggest you check whether the MSysACES exists on the current Access database.

Best Regards,

Edward

---

MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [e-mail].

Answer 9

We cracked the problem.

It was two fold. 

 1. Using a mapped drive.

 2. GPO settings in windows 7 for mapped drive use to 'update'.  The new behavior is 'replace'.  

What really irks me is when you cause this crash.  It's so horribly 'unhanded' inside msaccess source code, that the error appears to catastrophically cascade until JET itself dies.  example.  Follow my steps.  Cause the error.  Close the database.  In that same session of MsAccess, file -> new database -> BOOM you can't.  JET is dead in that instance of the msaccess.exe

What happens is every 90 minutes, or when a user goes idle the GPO will kick the mapped drive when it is set to replace.  This triggers the MsAccess critical failure of JET causing the ominous -1104 Reserved Error.  It can be manually tested by just bouncing a shared drive via net use.  But that's not as fun to watch as a 'gpupdate /force' then seeing access die.

1. Create a remote.mdb on a network folder \\machine\share\remote.mdb

 Add two tables.

2. net use K: \\machine\share

3. Create a local.mdb.  Link to those tables.

4. Open the local, and open table 1.

5. net use k: /delete and hit yes.

6. net use k: \\machine\share

7. Try and open table 2.  

You can replace step 2, 5, and 6 with a group policy to mount said share, and set the option to 'recreate'.  Then on step 5 just run gpupdate /force when msacess is open.  

Odd #1:  When this happens.  Our users are still able to interact with the form they are on.  In fact the form has a query to lookup customers first/last name etc.  They can issue a new lookup and it fetches just fine.  But if you try to open any other table, form, report, query you get -1104 over and over.

Odd #2: When this happens.  Access itself is DOA.  Close the database.  You can't open any other database or even create a blank one.

Odd #3: The fact that a GPO 'recreate', whereas MsAccess looses visibility to the share for just a second is not handled smoothly; and in fact gives a totally unrelated to this problem error message. -1104 denotes too many tables open.

Why the old developer used shared drives? I can't answer to.

Why the old IT guy allowed the shares to change from update to recreate? I can't answer to.

What I can say is how "access" handles this situation is piss poor and causing allot of people enormous amounts of time wasted. 

---

-Ryan Pavely Anderson-Kelly, Assoc.