Okay, I think I've got this licked...

I've added a test in the Control.xla file that uninstalls the add-in (but does not unregister it) every time the add-in is closed. Normally this is an issue, as it can be triggered by the user closing Excel, but when they cancel it leaves Excel open... but the add-in uninstalled. The thing is, with your setup though, that they can't open a workbook without installing the add-in. This means that if they have one open, they were already authorised. If they don't, it will check again to install the add-in.

Now, while the uninstall happens, the unregister doesn't. This isn't an issue, though, as it only throws an error when the add-in is loaded. Because our regular workbooks all have code to test for the existence of the add-in before it's opened, though, we won't get that error as we've intercepted it.

For any other users who happen along, I've attached a zip file with updated files as much as I did them, (database, xla and xls files,) although still not with John's "force macros" code inside. The add-in path and database paths need to be changed in the xls and xla files respectively.

So basically, Simon, unzip this file and use the new Control.xla (update the db path.) You should be set to go. Give it some tests and let me know.

The only time that I can see an issue happening is if the user has Excel open when they disconnect from the network. At that point they'll get the error. Monitoring that event, however, is going to need a VB coder and, most likely, a separate app that you'd need to install. (i.e. I don't think it's really feasible.)