Access errors after new server install

[kpg*]

Hi all,

A client of ours is runing a program we wrote in VB6, this program
uses an access database.

The client's server dies, so he replaced it with a new 2003 servr.

Now when he runs our program from the workstation here gets a series
of error, all error 1309, for example:

Error 1309. Error reading from file: C:\Program Files\Microsoft Office
\ART
\Pfiles\MSOffice\Office\MSO7FTP.EXE

There are 62 of theses, after which the program runs normally,

The workstation has a complete install of our software, including
the requires DAO and ADO files (we use both is various modules).

The sever is only used as a way to share the folder to several
workstatiosn.

Now I know that 2003 ships locked down more than, say 2000 server,
and I susspect that this error is the result of a security setting.

I had the user login an administrator on the workstation and they
still get the error.

One intenet help site says to re-install access, but the client
does not thing they have access installed, just our program.

does anyone know how to stop there error messages? here is
the complete list:


\Office\ACCESS.PIP
\Office\MSCAL.DEP
\Office\MSO7FTPA.EXE
This duplicates once then continues with:
\Office\1033\MSO.ACL
\Office\1033\GR8GALRY.GRA
\Office\1033\Utility.MDA
\ART\Pfiles\Snapview\SNAPVIEW.HLP
\ART\Pfiles\Snapview\README.TXT
\ART\Pfiles\Snapview\SNAPVIEW.CNT
\Office\Bitmaps\Styles\GLOBE.WMF
\Office\Bitmaps\Styles\ACBLENDS.GIF
\Office\Bitmaps\Styles\ACBLUPRT.GIF
\Office\Bitmaps\Styles\ACEXPDTN.GIF
\Office\Bitmaps\Styles\ACINDSTR.GIF
\Office\Bitmaps\Styles\ACRICEPR.GIF
\Office\Bitmaps\Styles\ACSNDSTN.GIF
\Office\Bitmaps\Styles\ACSUMIPT.GIF
\Office\Bitmaps\Styles\Stone.BMP
\Microsoft Office\ART\System\MSRECR40.DLL

Then is says:
Wait while Runtime Configures.

After which the program runs normally.

This occurs each time the program is run.

thanks,
kpg

 

[Jeff Boyce]

You don't mention whether the user/workstation has a copy of the
application's front-end or if the front-end or even the entire application
is located only on the server.

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[kpg*]

You don't mention whether the user/workstation has a copy of the

application's front-end or if the front-end or even the entire
application is located only on the server.

The app is stand alone - that is, it is not a client-server app,
and it is installed entirely on each workstation.

We use DAO 6.0 (Jet) to open the access files, other than that,
we do not use or require access to be installed.

The role of the sever is just so multiple workstations can
share a common database. It could just as well be a shared
folder on one of the workstations. The program runs entirely
on the workstation - the program exe and the database are
physically on the server, but all dlls are local to and registered
on the workstation.

This is why I find this error strange. The program worked fine
with the old server. While I don't know for sure, I assume they
retored our program from a backup onto the new server - everything
shoud just work since the workstations were not even touched by
the process. This is why I suspect a security/rights issue.

That bing said, all I really want to know is how to prevent
the error messages from coming up, either by "fixing" the
problem or somehow circumventing the problem.

kpg

 

[david]

Looks like you need to re-install the application. You
should also check what else is installed on that workstation.

Also I wonder about the VB6 program: do you still
have on staff anyone who wrote that program?

It looks like you are getting re-install messages for the
Access 95 runtime. Why would that be? What objects
does the VB6 build reference?

(david)

 

[kpg*]

@TK2MSFTNGP02.phx.gbl:

Thanks for the reply - answers inline:

Looks like you need to re-install the application.

We had the user run a program that copies and re-registers
all dll and ocx components of the program - essentially
a re-installation, with no effect. Note that the program
itself runs normally after the error messages clear up.

We have not tried a complete uninstall/reinstall as of yet.

You should also check what else is installed on that workstation.

Agreed - but we are not on site, the tech guy we are working with
is also not on site, and the user is, well, a typical user.

Also I wonder about the VB6 program: do you still
have on staff anyone who wrote that program?
Yes.

It looks like you are getting re-install messages for the
Access 95 runtime. Why would that be?

That is the question.

What objects does the VB6 build reference?

Aside from the 'normall' ones:

Microsoft DAO 3.6 Object Library
Microsoft XML 3.0
Micorosft Data Formatting Object Library 6.0 (SP6)
Microsoft Internet Controls
Microsoft Scripting Runtime

And these are in place and functioning fine. The files
the message box are complaining about have no bearing on
the program - all that is fine, but this was caused by
replacing the macine that hosts the share where the db is
located - the local workstation was not modified in any
way.

kpg

 

[Jeff Boyce]

It sounds like David has a better handle on this...

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[david]

located - the local workstation was not modified in any

way.

:~)

Got SBS and pushed a new copy of Outlook out to all the workstations?

MicroSoft Outlook7ftp is a stub program to handle the fact that there were
two incompatible versions of one of the system DLL's. And I think I was
wrong about Access 95: You may be looking at the 97 or 2000 runtime.

My guess is that you are using some component which is competing with some
other installation (for example, Outlook 2003) over what should be
installed. The component was originally installed by the Access Runtime
Version, and the user doesn't have full permission to re-run the
installation.

The fact that it's an ART installation sequence would lead me to suspect
"Microsoft Internet Controls", but I don't see that would help you any. All
I can suggest is that a person with full admin permissions should uninstall
and clean up the ART if possible.