Prev: Emailing Access Reports
Next: Back-up Bob Larson
From: david on 29 Dec 2007 00:20
Change to late binding, and fix everything that breaks.

This is to be sure that you are not implicitly creating any objects
that you aren't aware of.

Change all your named variables to comma counting:
wbk.Close savechanges:=True
becomes something like
wbk.Close,,,True

I don't know the comma counts: you will have to look that up.
This is to get rid of any variables which are actually creating objects
that you don't know about.

These are only general suggestions about using Excel Automation.
I don't know why Vista is different.

(david)

"scadav" <nospam(a)yahoo.com> wrote in message
news:mtqdnah6KeLvJenanZ2dnUVZ_ryqnZ2d(a)comcast.com...
> I did some more playing around with the code and was able to get Excel to
> close in Vista if I removed the line that says: wbk.Close savechanges:
> =True
>
> However, when I did this, it interactively popped up to the screen asking
> that I save the file. Once I chose to save the file and the code
finished,
> EXCEL.EXE would shutdown as a process.
>
> So I tried changing the wbk.Close savechanges:=True to wbk.SaveAs (as
> previously suggested). I also tried wbk.Save and wks.Save, but EXCEL.EXE
> would remain open still. (I obviously don't want this to interact with
the
> user).
>
> Two other pieces of interesting information is:
>
> #1 - if I leave the wbk.Close savechanges:=True in and open the file once
> it is complete I do not get an "this file is in use message"
> #2 -Once I close the file after opening it that instance of EXCEL.EXE will
> shutdown.
>
> Really need to solve this problem and hoping someone else has some ideas.


From: RoyVidar on 30 Dec 2007 06:38
It happens that david(a)epsomdotcomdotau formulated :
> Our automatic build process required us to modify the LocalServer32
> key to support user-level security. It just stopped working with
> Access 2000. I found that if I removed the
> LocalServer32\LocalServer32 key, the behaviour reverted to the use of
> the clear LocalServer32\default key.
>
> I formed the opinion that the new key pointed to the installation
> data (possibly to protect the user from automation spoofing), but
> I've never found any documentation at all. Documentation might be
> interesting, because (A) there might be a legitimate way to work with
> the current behaviour, and (B) it might shed some light on the
> behaviour of Access 2007 when installed on the same PC as 2003 etc.
>
> There is copious documentation on OLE, ActiveX, and COM, but it all
> dates from the time when MS was offering COM as an open standard
> competing with CORBA or JAVA beans. Nothing at all that I've ever
> found about the current behaviour of OLE or Windows Installer. MS
> OLE automation documentation seems to have stopped around 1999,
> as seen in the KB article.
>
> (david)

Interesting!

Thanx!

--
Roy-Vidar


First  |  Prev  | 
Pages: 1 2 3
Prev: Emailing Access Reports
Next: Back-up Bob Larson