Last week I experienced some weird behavior while trying to split a database I was working on (which took me a little while to figure out since my db had table relinking code included in it) and then yesterday fellow MVP Jack Leach started a discussion regarding the same problem. So having been confirmed by a 2nd completely independent source, I am dubbing it a bug.

The Bug

Here’s how you can reproduce the issue easily.

1. Create a new db and create a USysRibbons table to create a custom ribbon from. Set the db to use that ribbon.
2. Split the db, but place the USysRibbons table in the back-end (yes, this isn’t a best practice, but regardless).
3. Now, do one of 2 things:
   • Encrypt the back-end
   • Move the back-end file location

The next time you try to open your FE you will be presented with the default Access GUI to select the database you wish to open, as if you didn’t just ask it to open the FE. Even the Shift-Bypass will not work. As such, a relinking table function will not even fire.

The issue here being that Access’ bug does not give the developer/user any means to rectify it (as stated above, the even the shift-bypass does not work to get the developer back into the database to address the root cause of the problem), does not report any error, …

The Workaround

The solution is to deleted the linked table in the FE prior to encryption or relocating the BE and then recreating the linked table thereafter.

So basically, once you discover the problem you can’t actually address it.  You have to undo the encryption or relocation, so your FE will work again, delete the linked USysRibbons table, then make your changes, then relink the table.

Note

1. This problem only occurs with the USysRibbons table.  Other tables properly display the
   

   Could not find file ‘C:\…\…\…\databasename.accdb’

   when you try to access them after relocation or encryption.

2. I experienced the problem in Access 2013, and I believe Jack was having the issue in Access 2016.

The Bigger Question

The bigger question that should be asked here is why is it that a decade into the ribbon is it soooo fragile and temperamental without error reporting?  If you have flawed XML why can it not report the line causing the error?  Why in the above case, does this cause a fatal application error and not allow the developer any means to correct the situation?  Why has the ribbon stood still for 10 years now?!