CODEWITHSUNDEEP
vb.netprocessms-access-2010
Herbert
Herbert

Reputation: 181

MSAccess not opening database when started using System.Diagnostics.Process.Start()

I am having trouble to start an Access Database (msaccess.mdb) programmatically using System.Diagnostics.Process.Start().

This is the Scenario:

  1. vb.net aspx page starts [installpath]\cmd\ERPImport.exe
  2. ERPImport.exe reads settings from a SQL server db (pgmname, params, execdir) an uses again process.start() to start the batch file [installpath]\cmd\Import.cmd
  3. Import.cmd contains only these 3 lines:

G: cd \ESVONIX "C:\Program Files (x86)\Microsoft Office\Office14\msaccess.exe" "G:\ESVONIX\ESVONIX.mdb" /runtime

The esvonix.mdb is programmed to start some data manipulation in the startforms OnOpen Event. The startform is set in the db settings.

Now for the strange part:

BUT: if I start ERPImport.exe from within my vb.net page, it will start Import.cmd correctly and Import.cmd will start msaccess.exe (as I can see in taskmgr). However, Access does NOT open the database (no ldb file created) and does not start processing. It "hangs around" in the taskmgr with 0 cpu time used. After killing msaccess.exe from taskmgr the rest works fine again: Import.cmd completes, ERPImport completes, the aspx page Shows the result.

I have tried a large number of different Settings in process.startinfo, but the result is always the same, regardless of my Settings.

Any ideas are very welcome. Thanks

Upvotes: 1

Views: 443

Answers (1)

Herbert
Herbert

Reputation: 181

After changing from a full Office Installation to Access Runtime the Problem persisted, even without the /runtime Parameter in the call to Access. However, the Problem disappeared and Access was called and processed correctly with the command line Switch /save after the database Name in the command line.

UPDATE - Solved Unfortunately the /safe Parameter (requesting Access to start in Safe mode) did not fix the Problem. The process did run exactly once after adding the parameter and then went back to the previous behaviour.

The solution finally was to change the ApplicationPool settings to "LoadUserProfile = true". There are a number of questions on SO dealing with this Parameter. The exact reason in my case is not clear, but if it works ...

UPDATE July 11, 2017 Same Problem in a different user Environment. This time Windows 2012 Server. Setup worked with the combination of /safe Parameter when calling msaccess.exe and Setting the application pool to LoadUserProfile=true (in advanced Settings)

Upvotes: 1

Related Questions