Access 2003: Problem with Access.Application object when user not logged in

[Henk]

Dear readers,

I made a webapplication which invokes a DLL written in VB6, which in
turn invokes the Access.Application object to start Access and save a
generated report as a snapshot (.snp) file. The DLL and
Access.application object run in the security context of let's say
UserX. UserX is a Domain Admin (not nescessarily, but it's unimportant
for my story). This used to work fine with Access 2000. So far so good.


Now Access 2000 is upgraded to Access 2003 (without me knowing it) and
now this doesn't work anymore. The solution and code itself are fine. I

tested that. The weird thing is that it works fine as long as on the
webserver (w2003 srv) (which also hosts my DLL and the Access
application) UserX is logged on as the interactive user. As soon as the

user is logged off, the Access object is created, the app is started,
but never finishes. Obviously there is no display if the user is not
the interactive user.

From my experience i know that these sort of problems are usually

caused by the fact that in a user context without the user being the or

a interactive user, HKCU doesn't exist. Mostly these sort of problems
can be solved by creating/copying the right registry keys into the
HKU\.DEFAULT registry part. Furthermore i suspect that as Access 2003
is just installed, Access is asking UserX (which is not logged on) to
finish the installation, enter his initials or to disable or enable
macro's. I already logged in as UserX and answered these questions and
made the right macro security settings, but obviously these settings
get written to the HKCU part of the reg. I already copied this part to
HKU\.DEFAULT, but to no avail.

Does any of you know which registry keys i really need to copy to the
HKU\.DEFAULT part for Access 2003 to work when not logged on? Might
there be another problem causing this behaviour?

Thanks for your answers.

Henk Bertussen.

 

[david epsom dot com dot au]

The classic 'other' problem is not having a default printer
installed. Reports can't be painted unless there is a printer
defined, so even snapshots fail.

Using Terminal Services, my printers are created when I log
in, and destroyed when I log out. Is something similar happening
with your user?

With a little thought, you should be able to run a null
app without creating a report. If the null app hangs,
you know it is not the report, and is probably some
kind of permission problem. If the null app closes
correctly, you know it is probably the report, and
probably some kind of printer problem.

(david)