PLEASE ADVISE IF THERE IS A MORE APPROPRIATE NG FOR THIS TOPIC

Scenario:

Our application has the ability to merge data to word and then link the
merged document to a record in the database. Once the process is
complete, the users can open the record in the application, click a
button and the saved merge document is opened. When we execute the mail
merge from the application, it stores the current record ID in temp
file. The mail merge takes place and our VB script retrieves the record
ID and saves the merged document with filename = record ID.

We have two environments: Y (LIVE) & X (TEST)

The save location for Y is "Y:\Crtv2000\Crtv\Dktlink"
The save location for X is "X:\Crtv2000\Crtv\Dktlink"
Permissions for both = READ, WRITE, MODIFY, DELETE

Issue:

If I log onto PC #1 and perform the process in the Y environment, the
file is not saved due to "Error Number: 5582 - There has been a network
or file permission error. The network connection may be lost.
(Y:\Crtv2000\Crtv\Dktlink\35030886.doc)"

If I log onto PC #2 and perform the same operation, it works. This
makes me think there is a security at the PC level. I give myself admin
rights to PC #1, repeat the process and it then works. This, in my
mind, solidifies my theory that it's something at the PC level.

Next, I go to PC #3 and and test the process again. It does not work.
This time, instead of giving myself admin rights, I retry the process
using the X environment instead. It works.

So - I'm thinking there is some combination of share/user/PC security
eluding me. I've seen a lot of entries out there for the "There has
been a network or file permission error" error, but none fit my
circumstance. Please note that we've done this many time before for
many other clients with no problems.

ANY insight will be greatly appreciated

Regards,


--
Roy Ball
roy DOT ball AT gmail DOT com

PLEASE ADVISE IF THERE IS A MORE APPROPRIATE NG FOR THIS TOPIC

I'd say a group that deals with Windows server/network problems would
probably be the best place to ask. This really has nothing to do with the
mail merge technology.

Scenario:

Our application has the ability to merge data to word and then link the
merged document to a record in the database. Once the process is
complete, the users can open the record in the application, click a
button and the saved merge document is opened. When we execute the mail
merge from the application, it stores the current record ID in temp
file. The mail merge takes place and our VB script retrieves the record
ID and saves the merged document with filename = record ID.

We have two environments: Y (LIVE) & X (TEST)

The save location for Y is "Y:\Crtv2000\Crtv\Dktlink"
The save location for X is "X:\Crtv2000\Crtv\Dktlink"
Permissions for both = READ, WRITE, MODIFY, DELETE

Issue:

If I log onto PC #1 and perform the process in the Y environment, the
file is not saved due to "Error Number: 5582 - There has been a network
or file permission error. The network connection may be lost.
(Y:\Crtv2000\Crtv\Dktlink\35030886.doc)"

If I log onto PC #2 and perform the same operation, it works. This
makes me think there is a security at the PC level. I give myself admin
rights to PC #1, repeat the process and it then works. This, in my
mind, solidifies my theory that it's something at the PC level.

Next, I go to PC #3 and and test the process again. It does not work.
This time, instead of giving myself admin rights, I retry the process
using the X environment instead. It works.

So - I'm thinking there is some combination of share/user/PC security
eluding me. I've seen a lot of entries out there for the "There has
been a network or file permission error" error, but none fit my
circumstance. Please note that we've done this many time before for
many other clients with no problems.


Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail :-)

Cindy,

Thanks for your continued support. I'll post this to an appropriate NG.

For the benefit of others...

It appears this issue was related to security settings across for
replicated servers. When one server was taken out of the loop, the
issue went away.