shell runtime\msaccess doesn't always work if user is non admin

  • Thread starter Thread starter Andrew Brill
  • Start date Start date
A

Andrew Brill

Hi,
our system is split into 3 databases: a backend dataset, a front end mde and
a reporting mde.

The reports mde is lanuched using the following code:
Shell "c:\MyApp\office\msaccess.exe C:\MyApp\MyReports.mde /wrkgrp
C:\MyApp\system.mdw"

The icon for the app reads:
"C:\MyApp\Office\msaccess.exe C:\MyApp\MyApp.mde"

C:\MyApp\Office contains a customised runtime installation of access 97,
created outside pdw, that does not exhibit any of the documented problems
associated with use alongside other full/runtimes access versions (97
through XP tested fine on several hundred user installations)

The app loads perfectly under any circumstance. The reports database loads
fine under probably 98% of cases. In the remaining cases (which are always
win2k/xp machines) it only works if the user is logged in as a power user or
admin. We have many other users on 2k/xp without issues and we have never
been able to reproduce any problem. No power user level access rights
should be required and certainly no permissions beyond that used by the main
app.


We've got a major version release within the next couple of weeks and I'd
like to get this sorted out. The only obvious difference is that the shell
command specifies the workgroup file which is a throwback to when we used an
earlier version of our runtime installer. I'm not familar with what the
workgroup file is, beyond the fact that it needs one. Could it cause a
problem for non admin users? Or has anyone tried similar and experienced
(and hopefully resolved!) similar issues?

Thanks,
Andrew
 
In case anyone ever comes across similar I finally solved this yesterday
(after 2 years of trying!)

After using inctrl5 to monitor the registry I discovered the self
registering file msacc8.olb was attempting to update its path from the upper
case C: in the app launch string to the lower case c: in the reports
launching string! This path is stored in classes root which is not writable
to non admin users - hence the error! I can't believe the path check for
the file is case sensitive on a non-case sensitive OS! But hey, I'm just
happy to have fixed it.
 
Back
Top