Showing posts with label distributer. Show all posts
Showing posts with label distributer. Show all posts

Friday, March 30, 2012

Merge Rpl. Pull from subscriber access denied problem

Hi,
I have set up one laptop as the Distributer/Publisher. Went through the
wizard and set up a Publication also, used Pubs. Then registered another
remote laptop that I can see via the network, and it can see me. I went
through the wizard again and set up a Push to that laptop. Said it ran good,
and I can see the tables on the remote laptop now.
I deleted the Push and keep trying to create a Pull at the other laptop,
(subscriber). The wizard sets it up, but when it Starts Syncronizing, it
immediately gets the big Red X.
The error said The schema script
'\\ACER\ReplShare\ReplData\unc\ACER_pubs_pubs_arti cles\20050928212317\stores_1.sch' could not be propagated to the subscriber.
I can see this share from both ends. I have read a ton about the accounts
the agent has to run under in the last 12 hours, but can't see what I am
doing wrong.
Is there a trick here?
Thanks.
Steve,
try logging on to the subscriber laptop using the same account that the sql
server agent uses as a service account. The see if you can browse to the
snapshot folder
\\ACER\ReplShare\ReplData\unc\ACER_pubs_pubs_artic les\20050928212317. If you
can, see if you can copy the contents of this directory locally. I'm
guessing that the first part won't be possible due to permission
restrictions, but please post back with your results.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul,
I had tried some other things prior to being able to read your response.
Here is what I have done that is now working.
I set up new SQL users on both Publisher/Dist. and Subscriber, giving them
the proper roles. I then set up a new Windows login on each box, "Bob", of
type admin. I then changed both the MSSQLSERVICE and SQLAGENTSERVICE on each
to run under "Bob". When it asks for logon credintials for the subscriber, I
use the sa, when it asks for the publisher, I use the new SQL user I had set
up. Probably may have been able to use that for the subscriber instead of
the sa, don't know.
I have tried so many things since yesterday afternoon, I am a little unsure
as to what actually solved it. From all I read over night, having the two
service run under "Bob" was needed.
Thank you for the response,
Steve
"Paul Ibison" wrote:

> Steve,
> try logging on to the subscriber laptop using the same account that the sql
> server agent uses as a service account. The see if you can browse to the
> snapshot folder
> \\ACER\ReplShare\ReplData\unc\ACER_pubs_pubs_artic les\20050928212317. If you
> can, see if you can copy the contents of this directory locally. I'm
> guessing that the first part won't be possible due to permission
> restrictions, but please post back with your results.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||This is OK - what you've set up is known as pass-through authentication.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Is there a better or more preferred method? We have one laptop that acts as
the publisher/distributor, and two other laptops that will be subscribers.
They run over a wireless network. The two subscribers will be able to
initial pull merge replications.
Thanks,
Steve
"Paul Ibison" wrote:

> This is OK - what you've set up is known as pass-through authentication.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Steve,
are the laptops all on the same domain? If so, you could use a domain
account, which is given rights to the distributor's working folder. If not,
it's either pass-through, FTP, backup and restore or alternative snapshot
locations.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql

Monday, March 12, 2012

Merge Replication limit running in continuous mode

Hi,
We have a customer site running merge replication with a
publisher/distributer and 12 subscribers. All the merge agents are running in
continuous mode. It seems that two of the agents are always failed, or don't
last long. Is this directly related to the "number of concurrent merge
processes" number? It looks like because there are 10 merge agents *always*
running, the other two don't get a look in. Is this correct?
We can increase this number to 20 and the site seems to run ok, but we've
been hearing rumours that any number past 10 concurrent merge processes gets
unstable. What's the MS position on this?
What's the recommended solution to this situation? Schedule the agents
instead of continuous mode?
What is the error message generated by these two always failing agents?
Do you have the "limit the number of concurrent merge processes to the
following" option checked and set to 10.
What happens is that for long running merge agents the agents will timeout
or deadlock themselves, so MS advised you to limit the number that run
concurrently.
If you do choose this option you have to configure your agents to wait a
longer time before timing out. To do this right click on your merge agents,
select agent properties, click on the Steps tab, and double click on Run
Agent. Place focus in the commands text box, press End, and press the space
bar. enter -StartQueueTimeout 120
This will have the effect of having these two failing merge agents of
waiting up to 2 minutes for the first 10 merge agents in the queue to finish
their work.
I am not sure what the rational for 10 was. The fact it seems to work fine
when you bump it up to 20 seems to indicate that this throttling is not
optimal for you. I suspect that you did not use StartQueueTimeout option.
Running the agents in continuous mode will have no effect. The agents poll
by default every minute, so after the agent completes it will go to sleep
for a minute, and any agents in the queue will have their timeslice.
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
"Sydney" <hsc@.newsgroup.nospam> wrote in message
news:5C49D704-C649-41FA-8686-3EA92151867F@.microsoft.com...
> Hi,
> We have a customer site running merge replication with a
> publisher/distributer and 12 subscribers. All the merge agents are running
> in
> continuous mode. It seems that two of the agents are always failed, or
> don't
> last long. Is this directly related to the "number of concurrent merge
> processes" number? It looks like because there are 10 merge agents
> *always*
> running, the other two don't get a look in. Is this correct?
> We can increase this number to 20 and the site seems to run ok, but we've
> been hearing rumours that any number past 10 concurrent merge processes
> gets
> unstable. What's the MS position on this?
> What's the recommended solution to this situation? Schedule the agents
> instead of continuous mode?
>

Friday, March 9, 2012

Merge replication from SQL Server 2005 to 7.0

We are planning a merge replication using SQL Server 2005 as the distributer and publisher. Can any one give me any tips on using SQL Serever 7.0 as the subscriber?
you cannot use SQL7 - must upgrade to 2005 to use as merge subscriber.
ChrisB MCDBA
MSSQLConsulting.com
"William E. Booth" wrote:

> We are planning a merge replication using SQL Server 2005 as the distributer and publisher. Can any one give me any tips on using SQL Serever 7.0 as the subscriber?
>
|||This is from September 2007 BOL.<br /><br />SQL Server version 7.0 Service Pack 4 (SP4) is the earliest version that can participate in a replication topology with SQL Server 2005. If you use SQL Server 2000, SP3 or later is required.<br /><br />Look for this topic.<br />Using Multiple Versions of SQL Server in a Replication Topology<br /><br />