Workbook_Open event erroneously triggered when linking to xlsm workbook

98 views Asked by At

I am running a [Edit] read-only (3rd party!) [/Edit] SQL database, an xlsm, an xls (saved copy of the xlsm, just without macros), and an mdb (Access database).

They are linked as follows:

  • The xlsm gets data from the SQL database every 5 minutes by Application.OnTime code, triggered on Workbook_Open.
  • The xlsm then saves itself as a 2003 xls.
  • Since the code modules still exist at that moment (the workbook is not yet closed), I can open the Access mdb and refresh the Excel link to a table in the 2003 data, then close Access.

  • I then reopen the xlsm, triggering a new Application.Ontime instance.

  • I finally close the 2003 xls workbook.

This sequence runs during office hours and at the first run after 5pm sets a timer to start the process again in the morning.

My problem is whenever I open a file with a connection or link to the xlsm, the Workbook_Open event seems to trigger and I end up with the 2003 xls open on the 'client' computers. I know it's not just a leftover Application.OnTime on mine (the PC I originally created the files on) because now it's in use and other clients who have never opened the xlsm get the 2003 file randomly popping up when they're using Excel.

If that's not enough to trigger someone to know what's going on, I'll happily post code - but I am hoping someone has seen this before or knows of this rookie mistake and can simply give me a line I'm missing.

Thanks so much for your help!

3

There are 3 answers

0
Luuklag On BEST ANSWER

An easy solution would be to have all other files link to the .xls file, instead of the .xlsm macro enabled file. Downside to this approach would be that you have to (manually) update all your references.

2
Vegard On

I would think the reason the XLS pops up on your clients is because Excel has to open the linked XLSM in order to access the data, and as such, Workbook_Open gets triggered.

A few alternatives to the suggestions you have in the comments;

  • Check Environ("Username") before executing Application.OnTime so that it will only run if the file is opened by specific users.
  • Use a launcher-file to open the XLSM in "admin mode" - you can do this by using the launcher-file to set a Global-scope variable, and then have the XLSM check this variable before running Application.OnTime.
  • Make the XLSM test for some dummy-file on the local computer - one that you easily can create by hand on the computer you need regular access to the XLSM on. For example the XLSM can look for C:\Data\xlsm-enabler.txt or whatever works, and only run the relevant macro if the file exists.
  • Similar to the above, use SaveSetting to set a registry key on the "admin" machine(s) and check against this inside the XLSM.
  • Set your XLSM up to accept parameters, and use such parameters to open the file in "admin mode". This method is outlined several other places @ SO, like here.
  • This is more of a hunch - you might be able to leverage the Workbook.ReadOnly property in your XLSM as a conditional. This assumes that Excel opens the XLSM in readonly-mode when accessing it via data connections, which I don't know whether is actually the case.
2
HackSlash On

It would be way easier to do everything in Access. Then if you need to represent the data in Excel you can have a Workbook with a link to the Access table. This removes a step and it uses the right tool for the job. Access is for linking to database tables. Excel is for processing data views.

SQL > Access > Excel