Another merge agent for the subscription(s) is running

Hi everyone,
We are trying to implement merge replication using a central subscriber
model. When testing this out on 4 test machines, everything seemed fine.
Now, we are running a live test alongside our old system. So far we have the
central subscriber up and running and one publisher. The central subscriber
is using a one-way pull subscription to fetch the data from the publisher.
It pulls data once an hour.
The problem is that after a day or two, things stop working, and the merge
agent keeps failing and retrying to start the merge. The error from the
agent history is:
"Another merge agent for the subscription(s) is running."
Once I stop and start the sql agent service on the publisher, things work
fine for another day or two.
So my question is, why is this happening? I haven't been able to find
anything on the web about this particular error, other than to try using
this:
"select spid from sysprocesses where program_name = 'Your_Agent_Name'"
"Kill <spid>"
The problem with this solution is that I get no results from the select
statement, so there's no process to kill.
We are using MSDE 2000 Release A on Windows 2000 boxes. Any help would be
greatly appreciated.
Thanks,
-Brian
You get this when you are using WSM or the ActiveX controls to manage a pull
subscription and you also have a merge agent running. I have also seen it
when you script out publications and run them in a test environment and
don't change all the parameters.
You have to try to isolate this rouge agent.
"Brian Newtz" <anonymous@.discussions.microsoft.com> wrote in message
news:OP9lCvmEEHA.1128@.TK2MSFTNGP11.phx.gbl...
> Hi everyone,
> We are trying to implement merge replication using a central subscriber
> model. When testing this out on 4 test machines, everything seemed fine.
> Now, we are running a live test alongside our old system. So far we have
the
> central subscriber up and running and one publisher. The central
subscriber
> is using a one-way pull subscription to fetch the data from the publisher.
> It pulls data once an hour.
> The problem is that after a day or two, things stop working, and the merge
> agent keeps failing and retrying to start the merge. The error from the
> agent history is:
> "Another merge agent for the subscription(s) is running."
> Once I stop and start the sql agent service on the publisher, things work
> fine for another day or two.
> So my question is, why is this happening? I haven't been able to find
> anything on the web about this particular error, other than to try using
> this:
> "select spid from sysprocesses where program_name = 'Your_Agent_Name'"
> "Kill <spid>"
> The problem with this solution is that I get no results from the select
> statement, so there's no process to kill.
> We are using MSDE 2000 Release A on Windows 2000 boxes. Any help would be
> greatly appreciated.
> Thanks,
> -Brian
>
>
|||this message is raised after we check the sysprocesses table to see if any
SPID exists for the same application name as the merge agent.
You should try to detemine if the spids are being orphaned even after you
stop the agent, if so we need to determine the cause of that.
thanks
gopal
|||Hilary, Gopal,
I'm not using WSM or ActiveX controls for the pull subscription. What I did
was script out the replication and changed things as necessary in the
scripts to install it on the live servers.
Gopal - like I said, my problem is that when I try to get the spid of the
agent, there are no results returned... so I'm at a loss as to what to try.
Any other suggestions?
"Hilary Cotter" <hilaryk@.att.net> wrote in message
news:%23EG3DFnEEHA.3788@.TK2MSFTNGP10.phx.gbl...
> You get this when you are using WSM or the ActiveX controls to manage a
pull
> subscription and you also have a merge agent running. I have also seen it
> when you script out publications and run them in a test environment and
> don't change all the parameters.
> You have to try to isolate this rouge agent.
> "Brian Newtz" <anonymous@.discussions.microsoft.com> wrote in message
> news:OP9lCvmEEHA.1128@.TK2MSFTNGP11.phx.gbl...
> the
> subscriber
publisher.
merge
work
be
>

Another merge agent for the subscription is running

When trying to replicate I get the message "Another merge agent for the
subscription(s) is running."
Both publisher/distributor and subscriber are SQL2K SP3.
There is no orphan process for the agent in the sysprocesses table.
I monitored the sysprocesses while the agent is connecting: for few
seconds several processes added to the list with the host name of the
subscriber, all start and gone in the same time, and then I get the
message above.
Please help
Yes, the ActiveX is in use, but only it. No other agent for the
subscription is running.
The publication was created by hand with the wizard.
Rgds,
Orr
Paul Ibison wrote:
> It doesn't sound as though this applies, but have you
> used the ActiveX control or windows synchronization
> manager to initiate a pull when the merge agent was
> already running? Was your publication created by hand
> from scripts?
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
|||Problem solved!
The application that is using the ActiveX was started twice
automatically when computer booted.
Thanks,
Orr

Annon Merge over VPN: WSM Insanity

I have my replication "working", though I would like to script as much
of the client installation as possible, and running into mega
headaches.
Here's the setup:
Client - MSDE
connects to Publisher/Distributor via VPN
annonymous pull subscription
I can install my MSDE, create the db, logins, etc.
1) Through EM, I can create the subscription through wizard. (selecting
"Available to Synch Manager", "Start immediately"). It works.
Syncronization Manager (type in passwords) synch works.
2) I script the subscription created in 1). Delete subscription and run
script with osql (doesn't run Merge Agent job automatically. Why not? I
even put in an extra line: EXEC sp_start_job @.job_name =
'MERGE_AGENT_JOBNAME'). Go back to EM, right click on subsrciption -
Start Synchronizing. It works. WSM (type in passwords) synch works.
3). Delete subcription and recreate with same script as above. Go
straight to WSM. The subscription is in the list. Synch (type in
passwords). DOES NOT WORK!!! I get the error "the schema script <blah
blah blah> could not be propagated to the subscriber."
Why should I have to run the subscription once through EM before it
will work with WSM? I guess it has something to do with that Merge
Agent job and it needs to be fired off first?
Obviously EM will not be distributed to my end users in far off lands.
I want them to be able to run a script and then synch through WSM. What
is the best way to achieve this?
Much Thanks
answers in line.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<richerwin@.ubs-europe.org> wrote in message
news:1109180376.620053.87490@.o13g2000cwo.googlegro ups.com...
> I have my replication "working", though I would like to script as much
> of the client installation as possible, and running into mega
> headaches.
> Here's the setup:
> Client - MSDE
> connects to Publisher/Distributor via VPN
> annonymous pull subscription
> I can install my MSDE, create the db, logins, etc.
> 1) Through EM, I can create the subscription through wizard. (selecting
> "Available to Synch Manager", "Start immediately"). It works.
> Syncronization Manager (type in passwords) synch works.
I take it you are using SQL Authentication in WSM. If so your user will have
to enter the password each time WSM runs. You might want to use intergrated
authentication and enter the user account in the pal on the publisher.

> 2) I script the subscription created in 1). Delete subscription and run
> script with osql (doesn't run Merge Agent job automatically. Why not? I
> even put in an extra line: EXEC sp_start_job @.job_name =
> 'MERGE_AGENT_JOBNAME'). Go back to EM, right click on subsrciption -
> Start Synchronizing. It works. WSM (type in passwords) synch works.
The merge agent doesn't start automatically because you have defined it to
start on demand.

> 3). Delete subcription and recreate with same script as above. Go
> straight to WSM. The subscription is in the list. Synch (type in
> passwords). DOES NOT WORK!!! I get the error "the schema script <blah
> blah blah> could not be propagated to the subscriber."
This means that the subscriber does not have rights to read the snapshot
share. You will have to craft a new snapshot share which does not use the
administrative share (ie \\servername\c$\Program Files\Microsoft SQL
Server\MSSQL\ReplData\UNC). Make sure this new snapshot share has read
permission for the accounts or a group which the merge users are in, and
that this group or user has rights to read the underlying files and folders.
> Why should I have to run the subscription once through EM before it
> will work with WSM? I guess it has something to do with that Merge
> Agent job and it needs to be fired off first?
This does sound odd. Perhaps it is a rights issue.
> Obviously EM will not be distributed to my end users in far off lands.
> I want them to be able to run a script and then synch through WSM. What
> is the best way to achieve this?
> Much Thanks
>
|||
> This does sound odd. Perhaps it is a rights issue.
I create my subscription. Local machine is RICH-VAIO,
Publisher/Distributor is WSCLAN08; database is TMS. At both ends, the
SQL Server is the default instance.
1) I run the following Win2000 DOS BATCH command:
"C:\Program Files\Microsoft SQL Server\80\COM\replmerg.exe" -Publisher
[WSCLAN08] -PublisherDB [TMS] -Publication [pubUser100] -PublisherLogin
[tmsuser] -PublisherPassword [tmsuser] -Distributor [WSCLAN08]
-DistributorLogin [tmsuser] -DistributorPassword [tmsuser] -Subscriber
[RICH-VAIO] -SubscriberDB [TMS] -SubscriptionType 2
-SubscriberSecurityMode 0 -SubscriberLogin [tmsuser]
-SubscriberPassword []
and get the following log:
Microsoft SQL Server Merge Agent 8.00.760
Copyright (c) 2000 Microsoft Corporation
Connecting to Subscriber 'RICH-VAIO'
Connecting to Distributor 'WSCLAN08'
Initializing
Connecting to Publisher 'WSCLAN08'
Retrieving publication information
Retrieving subscription information
The subscription has been marked for reinitialization. Reinitialization
will occur the next time you synchronize this subscription.
The schema script
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
could not be propagated to the subscriber.
Category:NULL
Source: Merge Replication Provider
Number: -2147201001
Message: The schema script
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
could not be propagated to the subscriber.
Category:AGENT
Source: RICH-VAIO
Number: 0
Message: The process could not read file
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
due to OS error 1326.
Category:OS
Source:
Number: 1326
Message: Logon failure: unknown user name or bad password.
2) Immediately, I go to EM, right click on my subscription, and select
Start Synchronizing. The last entry in the log history is:
The job succeeded. The Job was invoked by User tmsuser. The last step
to run was step 1 (Run agent.).
3) Immediately, I run the same batch file as above. I get the following
log:
Microsoft SQL Server Merge Agent 8.00.760
Copyright (c) 2000 Microsoft Corporation
Connecting to Subscriber 'RICH-VAIO'
Connecting to Distributor 'WSCLAN08'
Initializing
Connecting to Publisher 'WSCLAN08'
Retrieving publication information
Retrieving subscription information
The merge process is cleaning up meta data in database 'TMS'.
The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
The merge process is cleaning up meta data in database 'TMS'.
The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
Uploading data changes to the Publisher
No data needed to be merged.
Downloading data changes to the Subscriber
4) Successive changes to the data at the subscriber are successfully
uploaded as in 3).
WHAT THE FREAK IS GOING ON WITH Merge Agent?
Please, please, please help. My kindom for a solution.
It must be noted I am not logged into Win2000 as tmsuser, though
tmsuser is a domain user under which SQLSERVER AGENT runs at the
subscriber, and tmsuser has full rights on the snapshot share at the
Publisher (as evident by the successful replications above).
|||just a wild thought here - why are you running the merge binary from the
command line?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<richerwin@.ubs-europe.org> wrote in message
news:1109221256.951320.175930@.f14g2000cwb.googlegr oups.com...
>
> I create my subscription. Local machine is RICH-VAIO,
> Publisher/Distributor is WSCLAN08; database is TMS. At both ends, the
> SQL Server is the default instance.
>
> 1) I run the following Win2000 DOS BATCH command:
> "C:\Program Files\Microsoft SQL Server\80\COM\replmerg.exe" -Publisher
> [WSCLAN08] -PublisherDB [TMS] -Publication [pubUser100] -PublisherLogin
> [tmsuser] -PublisherPassword [tmsuser] -Distributor [WSCLAN08]
> -DistributorLogin [tmsuser] -DistributorPassword [tmsuser] -Subscriber
> [RICH-VAIO] -SubscriberDB [TMS] -SubscriptionType 2
> -SubscriberSecurityMode 0 -SubscriberLogin [tmsuser]
> -SubscriberPassword []
> and get the following log:
> Microsoft SQL Server Merge Agent 8.00.760
> Copyright (c) 2000 Microsoft Corporation
> Connecting to Subscriber 'RICH-VAIO'
> Connecting to Distributor 'WSCLAN08'
> Initializing
> Connecting to Publisher 'WSCLAN08'
> Retrieving publication information
> Retrieving subscription information
> The subscription has been marked for reinitialization. Reinitialization
> will occur the next time you synchronize this subscription.
> The schema script
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> could not be propagated to the subscriber.
> Category:NULL
> Source: Merge Replication Provider
> Number: -2147201001
> Message: The schema script
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> could not be propagated to the subscriber.
> Category:AGENT
> Source: RICH-VAIO
> Number: 0
> Message: The process could not read file
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> due to OS error 1326.
> Category:OS
> Source:
> Number: 1326
> Message: Logon failure: unknown user name or bad password.
> 2) Immediately, I go to EM, right click on my subscription, and select
> Start Synchronizing. The last entry in the log history is:
> The job succeeded. The Job was invoked by User tmsuser. The last step
> to run was step 1 (Run agent.).
> 3) Immediately, I run the same batch file as above. I get the following
> log:
> Microsoft SQL Server Merge Agent 8.00.760
> Copyright (c) 2000 Microsoft Corporation
> Connecting to Subscriber 'RICH-VAIO'
> Connecting to Distributor 'WSCLAN08'
> Initializing
> Connecting to Publisher 'WSCLAN08'
> Retrieving publication information
> Retrieving subscription information
> The merge process is cleaning up meta data in database 'TMS'.
> The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
> in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
> The merge process is cleaning up meta data in database 'TMS'.
> The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
> in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
> Uploading data changes to the Publisher
> No data needed to be merged.
> Downloading data changes to the Subscriber
> 4) Successive changes to the data at the subscriber are successfully
> uploaded as in 3).
>
> WHAT THE FREAK IS GOING ON WITH Merge Agent?
> Please, please, please help. My kindom for a solution.
> It must be noted I am not logged into Win2000 as tmsuser, though
> tmsuser is a domain user under which SQLSERVER AGENT runs at the
> subscriber, and tmsuser has full rights on the snapshot share at the
> Publisher (as evident by the successful replications above).
>
|||
> why are you running the merge binary from the command line?
1) To show I'm getting the same results as from WSM.
2) So I can write the results to a log file with the >> redirect
command (so I can post them here) and show the group what I am doing.
3) End users won't have EM, so they need a way to start replication
(which isn't working from WSM, which is why I started this thread)
4) Proof of concept - it SHOULD work, shouldn't it?
thanks
|||[vbcol=seagreen]
This must have to do with accounts / permissions.
I have a couple of theories.
1) Why would executing the Merge agent job from within EM work, while
neither command-line nor WSM work? After all, I generated the
command-line args from the job from EM.
Is EM firing off the merge job under the same userID that I am when I
fire off the command line? (In the example above, both should be
'tmsuser'). How can I tell?
2) When I execute synchronize from WSM, do I have to be logged in to
Windows with the same domain ID that SQLSERVER AGENT (Windows service)
runs under?
Any help appreciated.
Thanks