1

MS Office 365 ProPlus, Access 2007 - 2016

I have a simple vbs script that runs a macro inside an MSACCESS DB...

set accessApp = CreateObject("Access.Application")
accessApp.OpenCurrentDatabase "\\sharedfileserver\somedir\mydb.accdb"
accessApp.Visible = false
accessApp.Run "Update_Burndown_Metrics"
accessApp.Quit

This script runs fine when I'm on my laptop (user = me). But when I log into another windows server and try to run the same script, I get...

Script C:\Users\dgauthie\Desktop\dbg.vbs
Line 4
Char 1
Error: Unknown runtime error
Code: 800A9D9F
Source: Microsoft VBScript runtime error

I wish I knew what 800A9D9F means. Not much in google for this one.

It feels like a permissions thing. But I'm logged in as me on both my laptop and the other windows server. (If it makes a diff, I log into the other server using "Remote Desktop Connection").

Any ideas ?

Addendum: Could the problem be rooted in a setting on the server where the problem exists... a safeguard against running code that manipulates external databases ? I'm a linux guy, not that familiar with windows, so I'm just grasping at straws.

daveg
  • 1,051
  • 11
  • 24
  • 1
    I suggest you ask IT staff. I suspect programmatic actions are blocked. – June7 May 28 '19 at 19:03
  • I don't have Access to test with on this box, but did you try the [Access.ApplicationError(long) method](https://learn.microsoft.com/en-us/office/vba/api/access.application.accesserror)? And did you try to open that database file directly / interactively? [Got this one too](https://stackoverflow.com/a/52573312/129130), don't think that will help you here. – Stein Åsmul May 28 '19 at 22:19
  • And I have never heard of it, but there is [Application.MacroError](https://learn.microsoft.com/en-us/office/vba/api/access.application.macroerror). – Stein Åsmul May 28 '19 at 22:24
  • https://www.pcreview.co.uk/threads/kallals-vbscript-and-scheduled-tasks.3258937/ - and other results in search results lead to specific problems with permissions for definite destinations. So what "But when I log into another windows server and try to run the same script, I get..." thing means? Do you run script from same location? Or where? – Van Ng May 29 '19 at 14:09
  • And one more thing: is MS Access installed on remote server, from where you are launching it? – Van Ng May 29 '19 at 14:10
  • I asked the IT dept to look into this. Thanks for the suggestion. – daveg May 29 '19 at 15:52
  • I tried the AccessApplicationError(long) method but it wouldn't take 800A9D9F (hex number). I converted to decimal and tried that, but got an overflow. Yes, I can open the DB from the server that has the problem and edit the table manually (good suggestion to check auth/permissions). – daveg May 29 '19 at 16:04
  • By "But when I log into another windows server and try to run the same script, I get..." I mean that I use RDC to log into a windows server (as me) that is not my laptop. It's actually a VM. From there I am able to open the subject Access DB and modify the problem table manually. But when I run the script (mentioned above) it fails. The same script runs fine from my laptop. – daveg May 29 '19 at 16:12
  • Yes, MSAccess is installed on the server where I am having the problem. The version there is "Microsoft Office 365 ProPlus". The version on my laptop is the same. – daveg May 29 '19 at 16:17
  • Could the problem be rooted in a setting on the server where the problem exists... a safeguard against running code that manipulates external databases ? I'm a linux guy, not that familiar with windows, so I'm just grasping at straws. – daveg May 29 '19 at 16:21
  • [Here is some information on DCOM and permissions](https://stackoverflow.com/a/56190794/129130). Whilst running **`oleview.exe`** with admin rights, try right clicking the relevant COM server entry and go **`"Create Instance"`**. You can even do that from the calling computer and go **`"Create Instance On..."`**. I haven't actually tried that, but maybe give it a go. – Stein Åsmul May 29 '19 at 22:56

2 Answers2

0

You're going to love this....

I prepared a copy of the vbs script, pointing it to a debug copy of the DB. I was going to hand this copy over to an IT guy for him to debug with. When I tested it, I was surprised to see that it ran OK. I pointed the copy back to the main, non-debug DB and tried that. It ran fine. I renamed the original vbs to "aside" and renamed the copy back to the original name and it runs fine. I compare "aside" to the working copy and they are identical.

Windows will never cease to amaze.

My suggestion to anyone that bumps into this is to make a copy and run that. Rename as needed !

daveg
  • 1,051
  • 11
  • 24
0

The problem returned when a new DB was used. The solution (for anyone else who hits this) was that the Access DB was prompting for "enable macros" interactively, and somehow this manifested in the 800A9D9F error code. Once I added the path to the trusted sources, the problem was fixed.

Lesson is... In Access, 800A9D9F can sometimes equate to a problem with macro enablement/disablement

daveg
  • 1,051
  • 11
  • 24