Sql Memory Leaks: error

Showing posts with label error. Show all posts

Wednesday, March 28, 2012

merge error rowguidcol

I setup merge, but when it was attempting to connect to the subscriber I
received an error (don't know exact text) about not being able to find
column rowguidcol. I ran:
SELECT name FROM syscolumns
And found lots of entries for rowguidcol, which is odd because I don't
name it that (each rowguid column in my table have unique names specific
to the table).
What command can I type to figure out what tables these rowguidcol's are
in?
Thank
Darin
*** Sent via Developersdex http://www.codecomments.com ***
Darin,
are you doing a nosync initialization? If so, it looks like the schema on
the publisher and subscriber are different. A rowguid column (with the
rowguid attribute) will be added to the replicated articles if it doesn't
already exist, and this should happen automatically.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||I am doing a nosync. The rowguid isn't being added (shouldn't be) since
all of my tables have rowguid column, but it is named (some examples),
ccst_rowguid, chst_rowguid, etc. This is what is confusing me.
I would say the schema should be the same because he (the customer) says
he is copying the data from one computer to the other, then I am setting
up replication.
Darin
*** Sent via Developersdex http://www.codecomments.com ***
|||OK - then adding the rowguid property to the table on the publisher and the
subscriber to the identical table should make it ok.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql

Merge error 2147200925 - why does reboot the server machine could solve problem.

Have a look at this article:
http://support.microsoft.com/?id=814916
There is a link to the hotfix details there.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Thanks,
I did take a look at it and have download the hot fix.
But could you explain why restarting the server can solve the problem
temporarily?
Pikctsach
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||A total guess here, but the problem occurs 'in certain circimstances' and
relates to teh production of temporary tables, so the initial population of
the tempdb database might play a part. Restarting the server will recreate
tempdb from the model database, and so reset the starting point - makes
sense locically but I have no way of determining if this is the case.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanks!
Have you ever thought of in whichscenarios, SQL Server creates the
temporary table name with a dash sign in the table name? (For Merge
Replication)
Why are temporary tables needed in Merge Replication?
Pikctsach.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!

Merge error

Hi,
the Merge-Agent stops with this error:
Columname 'rowguidcol' is invalid executing this command
{call sp_MSmakearticleprocs (?, ?)}
What is the reason for the error ?
How can I solve the problem ?
Regards
Leandro
do any of the articles you are replicating contain a column called
rowguidcol?
"Leandro Etchezar" <paralea@.ciudad.com.ar> wrote in message
news:%237lRvi3PFHA.3668@.TK2MSFTNGP14.phx.gbl...
> Hi,
> the Merge-Agent stops with this error:
> Columname 'rowguidcol' is invalid executing this command
> {call sp_MSmakearticleprocs (?, ?)}
> What is the reason for the error ?
> How can I solve the problem ?
> Regards
> Leandro
>

merge cannot be performed

I have an error in our replication server. The error reads, "The merge
process could not perform retention-based meta data cleanup in Database
"ourdatabasename".
The detail portion of the errors indicates that "The index entry for row ID
WAS NOT FOUND IN INDEX ID 2, of table 421576540 in database
"ourdatabasename".
does anybody know what this is and how we can fix it.
tx
run a DBCC reindex. You may have to drop the subscription to do this.
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
"tlee" <tlee@.lang.com> wrote in message
news:OVOpurdHFHA.3376@.TK2MSFTNGP14.phx.gbl...
> I have an error in our replication server. The error reads, "The merge
> process could not perform retention-based meta data cleanup in Database
> "ourdatabasename".
> The detail portion of the errors indicates that "The index entry for row
ID
> WAS NOT FOUND IN INDEX ID 2, of table 421576540 in database
> "ourdatabasename".
> does anybody know what this is and how we can fix it.
> tx
>
sql

Monday, March 26, 2012

Merge Agents Don't "Retry" After SQL Server Error 8645?

During a memory- and CPU-intensive nightly database update process, the
merge agents (running on the server) for two subscribers failed with
SQL Server Error 8645 (A time out occurred while waiting for memory
resources to execute the query). It's not surprising to see this error,
but the fact that the agents did not retry as configured is surprising.
I discovered that this message is listed as a "severity" of 17 - is
there some threshold that prevents a retry by the agent? A restart of
the agent was successful.
Justin H.
How many merge agents do you have? Are you limiting the number of concurrent
merge agents?
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
"Justin H." <jhenry@.gmail.com> wrote in message
news:1134585801.416828.82300@.g44g2000cwa.googlegro ups.com...
> During a memory- and CPU-intensive nightly database update process, the
> merge agents (running on the server) for two subscribers failed with
> SQL Server Error 8645 (A time out occurred while waiting for memory
> resources to execute the query). It's not surprising to see this error,
> but the fact that the agents did not retry as configured is surprising.
>
> I discovered that this message is listed as a "severity" of 17 - is
> there some threshold that prevents a retry by the agent? A restart of
> the agent was successful.
> Justin H.
>
|||There are only two subscribers, so two merge agents with no concurrency
limit configured. I'm not so concerned about the error as long as a
retry happens as configured.

merge Agent-login failure

I have 2 servers running on workgroups; merge replication
running SQL Server 2005 on each, snapshot running ok, start merge agent and
get this.
Error messages:
The merge process could not connect to the Publisher 'XXUSSHU18UT:Process'.
Check to ensure that the server is running. (Source: MSSQL_REPL, Error
number: MSSQL_REPL-2147198719)
Get help: http://help/MSSQL_REPL-2147198719
The process could not connect to Publisher 'XXUSSHU18UT'. (Source:
MSSQL_REPL, Error number: MSSQL_REPL20084)
Get help: http://help/MSSQL_REPL20084
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. (Source: MSSQLServer,
Error number: 18456)
Get help: http://help/18456
The easiest solution if you don't want to investigate the trust issue is to
switch the merge agent to be running under a SQL Server Login.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Hi,
I had similar problem few years ago when I was new to merge replication on
SQL Server 2000.
Create same windows account on both servers with same user name and same
password, run sql server end sql server agent on it and use this security
option for merge agent:
1. Run under SQL Server Agent service account
2. By impersonating the process account.
"bt7403" wrote:

> I have 2 servers running on workgroups; merge replication
> running SQL Server 2005 on each, snapshot running ok, start merge agent and
> get this.
> Error messages:
> The merge process could not connect to the Publisher 'XXUSSHU18UT:Process'.
> Check to ensure that the server is running. (Source: MSSQL_REPL, Error
> number: MSSQL_REPL-2147198719)
> Get help: http://help/MSSQL_REPL-2147198719
> The process could not connect to Publisher 'XXUSSHU18UT'. (Source:
> MSSQL_REPL, Error number: MSSQL_REPL20084)
> Get help: http://help/MSSQL_REPL20084
> Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. (Source: MSSQLServer,
> Error number: 18456)
> Get help: http://help/18456
|||connect to the publisher in SQL Server Management Studio, expand the local
publication folder, expand your publication, right click on the Subscriber
and select properties. In the Security Agent process account section click
on the three ellipses and enter a windows account which has in the dbo role
on the publication database or is in the PAL.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"bt7403" <bt7403@.discussions.microsoft.com> wrote in message
news:717FD769-249F-40EC-9425-116738AA1740@.microsoft.com...
>I have 2 servers running on workgroups; merge replication
> running SQL Server 2005 on each, snapshot running ok, start merge agent
> and
> get this.
> Error messages:
> The merge process could not connect to the Publisher
> 'XXUSSHU18UT:Process'.
> Check to ensure that the server is running. (Source: MSSQL_REPL, Error
> number: MSSQL_REPL-2147198719)
> Get help: http://help/MSSQL_REPL-2147198719
> The process could not connect to Publisher 'XXUSSHU18UT'. (Source:
> MSSQL_REPL, Error number: MSSQL_REPL20084)
> Get help: http://help/MSSQL_REPL20084
> Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. (Source:
> MSSQLServer,
> Error number: 18456)
> Get help: http://help/18456
|||Problem solved:
under SQL Security, I had to create a GUEST acct. and map this user to the
PUB db. Under Subscription Properties-Removed use of SQL Server Agent
service acct. and used Windows acct-maintained SQL Server Auth for Subscriber
connection.
Merge ran fine.
A side note:
Snapshot security settings do not require fine-tuning like Merge does.
I run this under SQL Server Agent service acct. and use SQL Server login for
connection to PUB.
thx. for your replies.
"Hilary Cotter" wrote:

> connect to the publisher in SQL Server Management Studio, expand the local
> publication folder, expand your publication, right click on the Subscriber
> and select properties. In the Security Agent process account section click
> on the three ellipses and enter a windows account which has in the dbo role
> on the publication database or is in the PAL.
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> 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
>
> "bt7403" <bt7403@.discussions.microsoft.com> wrote in message
> news:717FD769-249F-40EC-9425-116738AA1740@.microsoft.com...
>
>
sql

Merge Agent Error: invalid column 'rowguid'

I get this error when I Push New subscription and indicate NO, to initialize
schema and data.
the wizard dialog is: Initial Subscription, and I am choosing: No,
subscriber already has schema and data
Does the subscriber have an identical table ther already (including the guid
column)?
Regards,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||No. I just have four tables in my publication and checked for that first.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23W53vgb%23EHA.2608@.TK2MSFTNGP10.phx.gbl...
> Does the subscriber have an identical table ther already (including the
> guid
> column)?
> Regards,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Robert,
the table must already be there in a nosync initialization, in identical
format to the publisher one.
If you are saying it isn't there, then you'll need to use backup/restore or
DTS or some other means to transfer it.
Rgds,
Paul Ibison
"Robert A. DiFrancesco" <bob.difrancesco@.comcash.com> wrote in message
news:OoAgSmb%23EHA.2032@.tk2msftngp13.phx.gbl...
> No. I just have four tables in my publication and checked for that first.
>
> "Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
> news:%23W53vgb%23EHA.2608@.TK2MSFTNGP10.phx.gbl...
>
|||Thank you Paul. I feel special today with all your attention.
I meant the column rowguid; I checked that it was not present as I assume
the PushNewSubscription process will create the column in the table at the
subscriber.
What I really am trying to accomplish, and forgive me, is how do I "turn on
replication" at the publisher-machine when my subscriber machine is already
in a working-production environment?
My thinking is that I start with a blank database at the publisher, schema
matching the subscriber, and enable publishing and push a new subscription
but NOT intializing schema and data. Because I'm guessing the blank
database at the publisher will destroy all records at the live subscriber,
making it blank also. Am I correct and what is the solution?
Thank you very, very much.
Bob
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23dAW%23ub%23EHA.2804@.TK2MSFTNGP15.phx.gbl.. .
> Robert,
> the table must already be there in a nosync initialization, in identical
> format to the publisher one.
> If you are saying it isn't there, then you'll need to use backup/restore
> or
> DTS or some other means to transfer it.
> Rgds,
> Paul Ibison
> "Robert A. DiFrancesco" <bob.difrancesco@.comcash.com> wrote in message
> news:OoAgSmb%23EHA.2032@.tk2msftngp13.phx.gbl...
>
|||Robert,
please keep the questions coming - this is my great
hobby

The initialization process can do one of two things:
(a) if you choose a synch initialization, then the
complete table will be BCPd out into the repldata share.
In that share there'll be several textfiles - for
creating the schema, the indexes, one containing data,
but the initial text file contains simply a 'drop table'
statement. That means that it really doesn't matter what
is on the subscriber - there can be a table of the same
name or not. if there is, it'll be deleted anyway.
(b) you select to do a nosync initialization. In this
case, the exact ssame table (inc guid) must exist on the
subscriber. The initialization process will create
metadata tables on the subscriber, but it won't touch the
replicated table at all.
There are further variations if we consider other options
for @.pre_creation_cmd, where you can select to leave the
table there if it already exists and such like, but these
are for specialist scenarios.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Merge Agent error number 53 for replication

Hi, I am trying to setup replication between 2 SQL Servers across
non-trusted domains(2 different domains). I am able to successfully
registered both SQL servers in either domains. But I still cannot access the
snapshot folder in the Distributor/Publisher domain from the subscriber
domain.
* I've create the same SQL login: SQLAdmin and use this SQL authentication
on both the distributor and subscriber to interact with each other. They can
access each other fine, accept the subscriber cannot access the snapshot
folder on the distributor.
* I've given the Snapshot folder UNC path and Administrative share the
everyone permission.
********
I've read these Microsoft documents already:
Q321822 - Replicate between computers running SQL Server in Non-Trusted
Domains or Across the Internet.
Q240688 - Replication Subscribers Unable to Synchronize with Pull
Subscription.
Objective: I cannot create a pass-through account because the Distributor is
installed upon a Win2k Domain controller (with active directory), but I have
use SQL authentication on both SQL Server, but it still cannot access the
snapshot folder. All I need is for the subscriber to access the snapshot
folder. What do I need to do? Please list the steps, thanks...
****************************************
*****
The schema script
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040
311181629\snapshot.pre' could not be propagated to the subscriber.
****************************
The schema script
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040
311181629\snapshot.pre' could not be propagated to the subscriber.
(Source: Merge Replication Provider (Agent); Error number: -2147201001)
----
--
The process could not read file
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040
311181629\snapshot.pre' due to OS error 53.
(Source: ECSWEB (Agent); Error number: 0)
----
--
The network path was not found.
(Source: (OS); Error number: 53)
----
--
*************************
The schema script '\\MERCURY\G$\Program Files\Microsoft SQL
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury
Pub1\20040306225703\snapshot.pre' could not be propagated to the subscriber.
*************************
The schema script '\\MERCURY\G$\Program Files\Microsoft SQL
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury
Pub1\20040306225703\snapshot.pre' could not be propagated to the subscriber.
(Source: Merge Replication Provider (Agent); Error number: -2147201001)
----
--
The process could not read file '\\MERCURY\G$\Program Files\Microsoft SQL
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury
Pub1\20040306225703\snapshot.pre' due to OS error 53.
(Source: ECSWEB (Agent); Error number: 0)
----
--
The network path was not found.
(Source: (OS); Error number: 53)
----
--notice the unc path is completly wrong.
\\Mercury\REPLDATA\unc\MERCURY$MERCURY_N
orthwind_NorthwindMercuryPub1\200403
11181629\
its the dollar sign which I think is messing you up.
can you run run a net use * \\Mercury\REPLDATA on your subscriber and see if
you can map this drive. Then try to navigate upwards to the snapshot.pre
file?
Also if you could run this on your publisher/distributor and report back
here with what you get it will be helpful
select working_directory from msdb.dbo.MSdistpublishers
"Joe Mine" <huytuanattpgdotcomdotau> wrote in message
news:#ONwfV3BEHA.576@.TK2MSFTNGP11.phx.gbl...
> Hi, I am trying to setup replication between 2 SQL Servers across
> non-trusted domains(2 different domains). I am able to successfully
> registered both SQL servers in either domains. But I still cannot access
the
> snapshot folder in the Distributor/Publisher domain from the subscriber
> domain.
> * I've create the same SQL login: SQLAdmin and use this SQL authentication
> on both the distributor and subscriber to interact with each other. They
can
> access each other fine, accept the subscriber cannot access the snapshot
> folder on the distributor.
> * I've given the Snapshot folder UNC path and Administrative share the
> everyone permission.
> ********
> I've read these Microsoft documents already:
> Q321822 - Replicate between computers running SQL Server in Non-Trusted
> Domains or Across the Internet.
> Q240688 - Replication Subscribers Unable to Synchronize with Pull
> Subscription.
> Objective: I cannot create a pass-through account because the Distributor
is
> installed upon a Win2k Domain controller (with active directory), but I
have
> use SQL authentication on both SQL Server, but it still cannot access the
> snapshot folder. All I need is for the subscriber to access the snapshot
> folder. What do I need to do? Please list the steps, thanks...
>
> ****************************************
*****
> The schema script
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> 311181629\snapshot.pre' could not be propagated to the subscriber.
> ****************************
> The schema script
>[/color]
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> 311181629\snapshot.pre' could not be propagated to the subscriber.
> (Source: Merge Replication Provider (Agent); Error number: -2147201001)
> ----[/color]
--
> --
> The process could not read file
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> 311181629\snapshot.pre' due to OS error 53.
> (Source: ECSWEB (Agent); Error number: 0)
> ----[/color]
--
> --
> The network path was not found.
> (Source: (OS); Error number: 53)
> ----
--
> --
> *************************
> The schema script '\\MERCURY\G$\Program Files\Microsoft SQL
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> Pub1\20040306225703\snapshot.pre' could not be propagated to the[/color]
subscriber.
> *************************
> The schema script '\\MERCURY\G$\Program Files\Microsoft SQL
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> Pub1\20040306225703\snapshot.pre' could not be propagated to the[/color]
subscriber.
> (Source: Merge Replication Provider (Agent); Error number: -2147201001)
> ----
--
> --
> The process could not read file '\\MERCURY\G$\Program Files\Microsoft SQL
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> Pub1\20040306225703\snapshot.pre' due to OS error 53.
> (Source: ECSWEB (Agent); Error number: 0)
> ----[/color]
--
> --
> The network path was not found.
> (Source: (OS); Error number: 53)
> ----
--
> --
>
>|||Hilary,
I just ran the select working_directory on the Distributor and this
is the results:
working_directory
\\Mercury\REPLDATA
\\Mercury\REPLDATA
\\Mercury\REPLDATA
\\MERCURY\G$\Program Files\Microsoft SQL Server\MSSQL$MERCURY\ReplData
Yes I can net use * \\Mercury \REPLDATA and navigate to the snapshot.pre
file.
Regards
"Hilary Cotter" <hilaryk@.att.net> wrote in message
news:uPeVrH#BEHA.2404@.TK2MSFTNGP11.phx.gbl...
> notice the unc path is completly wrong.
>
\\Mercury\REPLDATA\unc\MERCURY$MERCURY_N
orthwind_NorthwindMercuryPub1\200403[col
or=darkred]
> 11181629\
> its the dollar sign which I think is messing you up.
> can you run run a net use * \\Mercury\REPLDATA on your subscriber and see[/color]
if
> you can map this drive. Then try to navigate upwards to the snapshot.pre
> file?
> Also if you could run this on your publisher/distributor and report back
> here with what you get it will be helpful
> select working_directory from msdb.dbo.MSdistpublishers
>
> "Joe Mine" <huytuanattpgdotcomdotau> wrote in message
> news:#ONwfV3BEHA.576@.TK2MSFTNGP11.phx.gbl...
> the
authentication
> can
Distributor
> is
> have
the
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> ----
> --
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> ----
> --
> ----
> --
>[/color]
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> subscriber.
>[/color]
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> subscriber.
> ----
> --
SQL
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> ----
> --
> ----
> --
>[/color]|||Now I even got error no: 1326
The schema script
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040
311181629\snapshot.pre' could not be propagated to the subscriber.
(Source: Merge Replication Provider (Agent); Error number: -2147201001)
----
--
The process could not read file
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040
311181629\snapshot.pre' due to OS error 1326.
(Source: ECSWEB (Agent); Error number: 0)
----
--
Logon failure: unknown user name or bad password.
(Source: (OS); Error number: 1326)
----
--
"Joe Mine" <huytuanattpgdotcomdotau> wrote in message
news:#8btBY#BEHA.3784@.TK2MSFTNGP10.phx.gbl...
> Hilary,
> I just ran the select working_directory on the Distributor and
this
> is the results:
> working_directory
> \\Mercury\REPLDATA
> \\Mercury\REPLDATA
> \\Mercury\REPLDATA
> \\MERCURY\G$\Program Files\Microsoft SQL Server\MSSQL$MERCURY\ReplData
>
> Yes I can net use * \\Mercury \REPLDATA and navigate to the snapshot.pre
> file.
> Regards
>
>
> "Hilary Cotter" <hilaryk@.att.net> wrote in message
> news:uPeVrH#BEHA.2404@.TK2MSFTNGP11.phx.gbl...
>
\\Mercury\REPLDATA\unc\MERCURY$MERCURY_N
orthwind_NorthwindMercuryPub1\200403[col
or=darkred]
see
> if
access
subscriber
> authentication
They
snapshot
Non-Trusted
> Distributor
I
> the
snapshot
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
number: -2147201001)
> ----
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> ----
> ----
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
>[/color]
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
number: -2147201001)
> ----
> SQL
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> ----
> ----
>[/color]|||I take it you have moved to using SQL Server Standard security in your
enabled subscriber.
Is this account in the PAL for the publication. Right click on your
publication in the publication database, select publication properties, and
go to Publication Access List. The account you are using must be in the
server administrator role on the subscriber, and in the dbo role on the
publication database. It also must be present in the PAL.
Also verify that the password you are using is correct. To do this, go to
Tools-Replication-Configure Publishers, Distributors, Subscribers, click on
the Subscribers tab, and locate your Subscriber. Then click on the browse
button to the right of your Subscribers, and then in the Use SQL Server
Authentication enter the correct information.
"Joe Mine" <huytuanattpgdotcomdotau> wrote in message
news:OeNZV$$BEHA.1588@.tk2msftngp13.phx.gbl...
> Now I even got error no: 1326
>
> The schema script
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> 311181629\snapshot.pre' could not be propagated to the subscriber.
> (Source: Merge Replication Provider (Agent); Error number: -2147201001)
> ----[/color]
--
> --
> The process could not read file
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> 311181629\snapshot.pre' due to OS error 1326.
> (Source: ECSWEB (Agent); Error number: 0)
> ----[/color]
--
> --
> Logon failure: unknown user name or bad password.
> (Source: (OS); Error number: 1326)
> ----
--
> --
> "Joe Mine" <huytuanattpgdotcomdotau> wrote in message
> news:#8btBY#BEHA.3784@.TK2MSFTNGP10.phx.gbl...
> this
snapshot.pre
>
\\Mercury\REPLDATA\unc\MERCURY$MERCURY_N
orthwind_NorthwindMercuryPub1\200403[col
or=darkred]
> see
snapshot.pre
back
> access
> subscriber
> They
> snapshot
the
> Non-Trusted
but
> I
access
> snapshot
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> number: -2147201001)
> ----
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> ----
> ----
>[/color]
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
>[/color]
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> number: -2147201001)
> ----
Files\Microsoft
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> ----
> ----
>[/color]

Merge Agent error number 53 for replication

Hi, I am trying to setup replication between 2 SQL Servers across
non-trusted domains(2 different domains). I am able to successfully
registered both SQL servers in either domains. But I still cannot access the
snapshot folder in the Distributor/Publisher domain from the subscriber
domain.
* I've create the same SQL login: SQLAdmin and use this SQL authentication
on both the distributor and subscriber to interact with each other. They can
access each other fine, accept the subscriber cannot access the snapshot
folder on the distributor.
* I've given the Snapshot folder UNC path and Administrative share the
everyone permission.
********
I've read these Microsoft documents already:
Q321822 - Replicate between computers running SQL Server in Non-Trusted
Domains or Across the Internet.
Q240688 - Replication Subscribers Unable to Synchronize with Pull
Subscription.
Objective: I cannot create a pass-through account because the Distributor is
installed upon a Win2k Domain controller (with active directory), but I have
use SQL authentication on both SQL Server, but it still cannot access the
snapshot folder. All I need is for the subscriber to access the snapshot
folder. What do I need to do? Please list the steps, thanks...
****************************************
*****
The schema script
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040
311181629\snapshot.pre' could not be propagated to the subscriber.
****************************
The schema script
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040
311181629\snapshot.pre' could not be propagated to the subscriber.
(Source: Merge Replication Provider (Agent); Error number: -2147201001)
----
--
The process could not read file
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040
311181629\snapshot.pre' due to OS error 53.
(Source: ECSWEB (Agent); Error number: 0)
----
--
The network path was not found.
(Source: (OS); Error number: 53)
----
--
*************************
The schema script '\\MERCURY\G$\Program Files\Microsoft SQL
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury
Pub1\20040306225703\snapshot.pre' could not be propagated to the subscriber.
*************************
The schema script '\\MERCURY\G$\Program Files\Microsoft SQL
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury
Pub1\20040306225703\snapshot.pre' could not be propagated to the subscriber.
(Source: Merge Replication Provider (Agent); Error number: -2147201001)
----
--
The process could not read file '\\MERCURY\G$\Program Files\Microsoft SQL
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury
Pub1\20040306225703\snapshot.pre' due to OS error 53.
(Source: ECSWEB (Agent); Error number: 0)
----
--
The network path was not found.
(Source: (OS); Error number: 53)
----
--OS Error 53 == Network Name not found.
Check for Name resolution problems with either WINS or DNS.
Verify you can get to the server from the client using the "net view
\\servername" command.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||notice the unc path is completly wrong.
\\Mercury\REPLDATA\unc\MERCURY$MERCURY_N
orthwind_NorthwindMercuryPub1\200403
11181629\
its the dollar sign which I think is messing you up.
can you run run a net use * \\Mercury\REPLDATA on your subscriber and see if
you can map this drive. Then try to navigate upwards to the snapshot.pre
file?
Also if you could run this on your publisher/distributor and report back
here with what you get it will be helpful
select working_directory from msdb.dbo.MSdistpublishers
"Joe Mine" <huytuanattpgdotcomdotau> wrote in message
news:#ONwfV3BEHA.576@.TK2MSFTNGP11.phx.gbl...
> Hi, I am trying to setup replication between 2 SQL Servers across
> non-trusted domains(2 different domains). I am able to successfully
> registered both SQL servers in either domains. But I still cannot access
the
> snapshot folder in the Distributor/Publisher domain from the subscriber
> domain.
> * I've create the same SQL login: SQLAdmin and use this SQL authentication
> on both the distributor and subscriber to interact with each other. They
can
> access each other fine, accept the subscriber cannot access the snapshot
> folder on the distributor.
> * I've given the Snapshot folder UNC path and Administrative share the
> everyone permission.
> ********
> I've read these Microsoft documents already:
> Q321822 - Replicate between computers running SQL Server in Non-Trusted
> Domains or Across the Internet.
> Q240688 - Replication Subscribers Unable to Synchronize with Pull
> Subscription.
> Objective: I cannot create a pass-through account because the Distributor
is
> installed upon a Win2k Domain controller (with active directory), but I
have
> use SQL authentication on both SQL Server, but it still cannot access the
> snapshot folder. All I need is for the subscriber to access the snapshot
> folder. What do I need to do? Please list the steps, thanks...
>
> ****************************************
*****
> The schema script
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> 311181629\snapshot.pre' could not be propagated to the subscriber.
> ****************************
> The schema script
>[/color]
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> 311181629\snapshot.pre' could not be propagated to the subscriber.
> (Source: Merge Replication Provider (Agent); Error number: -2147201001)
> ----[/color]
--
> --
> The process could not read file
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> 311181629\snapshot.pre' due to OS error 53.
> (Source: ECSWEB (Agent); Error number: 0)
> ----[/color]
--
> --
> The network path was not found.
> (Source: (OS); Error number: 53)
> ----
--
> --
> *************************
> The schema script '\\MERCURY\G$\Program Files\Microsoft SQL
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> Pub1\20040306225703\snapshot.pre' could not be propagated to the[/color]
subscriber.
> *************************
> The schema script '\\MERCURY\G$\Program Files\Microsoft SQL
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> Pub1\20040306225703\snapshot.pre' could not be propagated to the[/color]
subscriber.
> (Source: Merge Replication Provider (Agent); Error number: -2147201001)
> ----
--
> --
> The process could not read file '\\MERCURY\G$\Program Files\Microsoft SQL
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> Pub1\20040306225703\snapshot.pre' due to OS error 53.
> (Source: ECSWEB (Agent); Error number: 0)
> ----[/color]
--
> --
> The network path was not found.
> (Source: (OS); Error number: 53)
> ----
--
> --
>
>|||Hilary,
I just ran the select working_directory on the Distributor and this
is the results:
working_directory
\\Mercury\REPLDATA
\\Mercury\REPLDATA
\\Mercury\REPLDATA
\\MERCURY\G$\Program Files\Microsoft SQL Server\MSSQL$MERCURY\ReplData
Yes I can net use * \\Mercury \REPLDATA and navigate to the snapshot.pre
file.
Regards
"Hilary Cotter" <hilaryk@.att.net> wrote in message
news:uPeVrH#BEHA.2404@.TK2MSFTNGP11.phx.gbl...
> notice the unc path is completly wrong.
>
\\Mercury\REPLDATA\unc\MERCURY$MERCURY_N
orthwind_NorthwindMercuryPub1\200403[col
or=darkred]
> 11181629\
> its the dollar sign which I think is messing you up.
> can you run run a net use * \\Mercury\REPLDATA on your subscriber and see[/color]
if
> you can map this drive. Then try to navigate upwards to the snapshot.pre
> file?
> Also if you could run this on your publisher/distributor and report back
> here with what you get it will be helpful
> select working_directory from msdb.dbo.MSdistpublishers
>
> "Joe Mine" <huytuanattpgdotcomdotau> wrote in message
> news:#ONwfV3BEHA.576@.TK2MSFTNGP11.phx.gbl...
> the
authentication
> can
Distributor
> is
> have
the
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> ----
> --
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> ----
> --
> ----
> --
>[/color]
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> subscriber.
>[/color]
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> subscriber.
> ----
> --
SQL
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> ----
> --
> ----
> --
>[/color]|||Now I even got error no: 1326
The schema script
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040
311181629\snapshot.pre' could not be propagated to the subscriber.
(Source: Merge Replication Provider (Agent); Error number: -2147201001)
----
--
The process could not read file
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040
311181629\snapshot.pre' due to OS error 1326.
(Source: ECSWEB (Agent); Error number: 0)
----
--
Logon failure: unknown user name or bad password.
(Source: (OS); Error number: 1326)
----
--
"Joe Mine" <huytuanattpgdotcomdotau> wrote in message
news:#8btBY#BEHA.3784@.TK2MSFTNGP10.phx.gbl...
> Hilary,
> I just ran the select working_directory on the Distributor and
this
> is the results:
> working_directory
> \\Mercury\REPLDATA
> \\Mercury\REPLDATA
> \\Mercury\REPLDATA
> \\MERCURY\G$\Program Files\Microsoft SQL Server\MSSQL$MERCURY\ReplData
>
> Yes I can net use * \\Mercury \REPLDATA and navigate to the snapshot.pre
> file.
> Regards
>
>
> "Hilary Cotter" <hilaryk@.att.net> wrote in message
> news:uPeVrH#BEHA.2404@.TK2MSFTNGP11.phx.gbl...
>
\\Mercury\REPLDATA\unc\MERCURY$MERCURY_N
orthwind_NorthwindMercuryPub1\200403[col
or=darkred]
see
> if
access
subscriber
> authentication
They
snapshot
Non-Trusted
> Distributor
I
> the
snapshot
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
number: -2147201001)
> ----
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> ----
> ----
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
>[/color]
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
number: -2147201001)
> ----
> SQL
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> ----
> ----
>[/color]|||I take it you have moved to using SQL Server Standard security in your
enabled subscriber.
Is this account in the PAL for the publication. Right click on your
publication in the publication database, select publication properties, and
go to Publication Access List. The account you are using must be in the
server administrator role on the subscriber, and in the dbo role on the
publication database. It also must be present in the PAL.
Also verify that the password you are using is correct. To do this, go to
Tools-Replication-Configure Publishers, Distributors, Subscribers, click on
the Subscribers tab, and locate your Subscriber. Then click on the browse
button to the right of your Subscribers, and then in the Use SQL Server
Authentication enter the correct information.
"Joe Mine" <huytuanattpgdotcomdotau> wrote in message
news:OeNZV$$BEHA.1588@.tk2msftngp13.phx.gbl...
> Now I even got error no: 1326
>
> The schema script
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> 311181629\snapshot.pre' could not be propagated to the subscriber.
> (Source: Merge Replication Provider (Agent); Error number: -2147201001)
> ----[/color]
--
> --
> The process could not read file
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> 311181629\snapshot.pre' due to OS error 1326.
> (Source: ECSWEB (Agent); Error number: 0)
> ----[/color]
--
> --
> Logon failure: unknown user name or bad password.
> (Source: (OS); Error number: 1326)
> ----
--
> --
> "Joe Mine" <huytuanattpgdotcomdotau> wrote in message
> news:#8btBY#BEHA.3784@.TK2MSFTNGP10.phx.gbl...
> this
snapshot.pre
>
\\Mercury\REPLDATA\unc\MERCURY$MERCURY_N
orthwind_NorthwindMercuryPub1\200403[col
or=darkred]
> see
snapshot.pre
back
> access
> subscriber
> They
> snapshot
the
> Non-Trusted
but
> I
access
> snapshot
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> number: -2147201001)
> ----
>
'\\Mercury\REPLDATA\unc\MERCURY$MERCURY_
Northwind_NorthwindMercuryPub1\20040[col
or=darkred]
> ----
> ----
>[/color]
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
>[/color]
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> number: -2147201001)
> ----
Files\Microsoft
>
Server\MSSQL$MERCURY\ReplData\unc\MERCUR
Y$MERCURY_Northwind_NorthwindMercury[col
or=darkred]
> ----
> ----
>[/color]|||All I need is for the subscriber to access the snapshot
folder. What do I need to do? Please list the steps, thanks...
****************************************
******************************
Sent via Fuzzy Software @. http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET
resources...sql

merge agent error

We are using HTTPS merge replication.

One of my subscribers is getting this error:

Error messages:

The Merge Agent failed after detecting that retention-based metadata cleanup has deleted metadata at the Publisher for changes not yet sent to the Subscriber. You must reinitialize the subscription (without upload). (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199402)

This is a bit surprising - it has been working fine - and also there were no changes at the publisher (it only has one article in this publication - a stored proc)

Why would this have happened ? The retention period is 45 days and they synchronised successfully only a few days prior.

thanks

1. How often (frequently) does your app do merge between the publisher and this subscriber? If you had other subscribers and have done merge sync, did the same issue raise?

2. What if you select last_sync_date and metadatacleanuptime from sysmergesubscriptions on the publication database?

Thanks.

This posting is provided "AS IS" with no warranties, and confers no rights

|||

Thanks for replying.

1. It syncs up every day

2. last_sync_date = 2006-04-28 21:28:58.803
metadatacleanuptime = 2006-05-02 17:37:25.420

We have a number of clients for whom we setup merge replication. For each database we create two publications

1) the first publication has all the data and procs - it is setup with the syncType set to None. Therefore when we initialise the subscription the subscriber already has the data and schema.

2) the second publication only has one proc initially - it is setup with the syncType set to Automatic - we use this publication if we need to add any tables or procs to the database - it obviously has a much smaller snapshot

We have noticed that it is the second publication which is often getting this error - even though the clients are regularly synchronising....

Regards
Bruce

|||

Any ideas on this ?

Thanks
Bruce

|||

Hi Bruce, it looks like an existing bug in SQL 2005 which is slated to be fixed in SP2. Can you confirm that "select use_partition_groups from sysmergepublications" has value of 0 for both your publications?

Also, how many articles are in the other publication?

|||

Thanks for the response - I'm away for the next 5 days so can't get the answer on use_partition_groups yet...

In the other publication - there are about 600 I s'pose - 100 old tables and 500 procs or more.

Is there any way to stop this happening until sp2 ? We are rolling this out at the moment...

Thanks

|||One last question - you mentioned the subscribers sync daily, yet there's four days difference between last sync time and the metadata cleanup time. Do you know what happened between 4/28 and 5/2? Did the agent not sync?|||

It syncs every day if the pc is on ! This client turns it off on the weekend.

Yes - use_partition_groups is set to 0 for both publications

In case it matters the subscriptions are setup as follows:

subscription.CreateSyncAgentByDefault = False -- I wrote a windows service to synchronise
subscription.UseWebSynchronization = True
subscription.InternetSecurityMode = AuthenticationMethod.BasicAuthentication
subscription.SubscriberType = MergeSubscriberType.Anonymous

As there is only one proc in the second publication at the moment (and it is a trivial proc) I can reinitialise it and I guess this will be a workaround for now - but as soon as I need to add tables to this for future releases I will not want to be doing this. Is it a matter of hanging out until SP2 for a fix for this ? I guess that will be 3/4 months away or worse.

One more question about reinitialising subscriptions. When marking the publication for reinitialization from the publisher, I right-click on the publication name and have to select 'reinitialize all subscriptions' (I'm guessing that because the subscriber type is anonymous I can't select the individual subscriber if there are multiple subscribers to this publication), I get a message box asking me to confirm and whether to use the current snapshot or to create a new one. What is most disconcerting is that it doesn't specify which publication it is doing this for. Just for my own sanity, can you confirm it is only doing this for the publication you are selecting, and not all of them !!!! Paranoid I know but it's always better to ask I think..

Thanks
Bruce

|||

hi Greg

Any further update on a fix for this ?

Thanks
Bruce

|||

Bruce,

You can wait for Service pack 2 for the fix.

As a workaround, what you can do is increase the retention period of the publications. That way, the possibility of hitting the bug is lesser.

As per your question of reintializing the publication, all subscriptions to the publication you right clicked (and chose reinitialize) will be renitialized. No other publication will be affected.

|||

FYI,

We are having the same issue and are eagerly awaiting SP2 or a hotfix.

|||

We are having a similar issue but it is the other way round.

The Merge Agent failed after detecting that retention-based metadata cleanup has deleted metadata at the Subscriber for changes not yet sent to the Publisher. You must reinitialize the subscription (without upload).

This has started to happen only after we have set-up a second publication. We have set the retention period to 5 days on both the publications. We replicate data every 3 minutes and hence 5 days is a long time for data not to replicate.

Any ideas as to why we are getting this problem? Is this a known issue?

|||

I posted a visual guide to addressing this issue at: http://www.vsteamsystemcentral.com/cs/blogs/applied_team_system/archive/2006/08/13/128.aspx.

:{> Andy

|||We have also run into this error, and have used the work around of extending our expiration out to 999 days.

I am wondering if we will be running into performance issues soon because the metadata will not be cleaned up often enough. Will the tables get extrememly large? Is there a way to do the cleanup manually if performance suffers enough?

Is SP2 close to being released?

thanks,
jg

|||

Do subscribers and publishers both need to be upgraded to SP2a for this to be fixed

We upgraded the publisher, and this is still happening.

I'll see if it happens to any of the subscribers after we upgrade them to sp2a.

Bruce

merge agent error

We are using HTTPS merge replication.

One of my subscribers is getting this error:

Error messages:

This is a bit surprising - it has been working fine - and also there were no changes at the publisher (it only has one article in this publication - a stored proc)

Why would this have happened ? The retention period is 45 days and they synchronised successfully only a few days prior.

thanks

1. How often (frequently) does your app do merge between the publisher and this subscriber? If you had other subscribers and have done merge sync, did the same issue raise?

2. What if you select last_sync_date and metadatacleanuptime from sysmergesubscriptions on the publication database?

Thanks.

This posting is provided "AS IS" with no warranties, and confers no rights

|||

Thanks for replying.

1. It syncs up every day

2. last_sync_date = 2006-04-28 21:28:58.803
metadatacleanuptime = 2006-05-02 17:37:25.420

We have a number of clients for whom we setup merge replication. For each database we create two publications

1) the first publication has all the data and procs - it is setup with the syncType set to None. Therefore when we initialise the subscription the subscriber already has the data and schema.

We have noticed that it is the second publication which is often getting this error - even though the clients are regularly synchronising....

Regards
Bruce

|||

Any ideas on this ?

Thanks
Bruce

|||

Also, how many articles are in the other publication?

|||

Thanks for the response - I'm away for the next 5 days so can't get the answer on use_partition_groups yet...

In the other publication - there are about 600 I s'pose - 100 old tables and 500 procs or more.

Is there any way to stop this happening until sp2 ? We are rolling this out at the moment...

Thanks

It syncs every day if the pc is on ! This client turns it off on the weekend.

Yes - use_partition_groups is set to 0 for both publications

In case it matters the subscriptions are setup as follows:

Thanks
Bruce

|||

hi Greg

Any further update on a fix for this ?

Thanks
Bruce

|||

Bruce,

You can wait for Service pack 2 for the fix.

As a workaround, what you can do is increase the retention period of the publications. That way, the possibility of hitting the bug is lesser.

As per your question of reintializing the publication, all subscriptions to the publication you right clicked (and chose reinitialize) will be renitialized. No other publication will be affected.

|||

FYI,

We are having the same issue and are eagerly awaiting SP2 or a hotfix.

|||

We are having a similar issue but it is the other way round.

Any ideas as to why we are getting this problem? Is this a known issue?

|||

I posted a visual guide to addressing this issue at: http://www.vsteamsystemcentral.com/cs/blogs/applied_team_system/archive/2006/08/13/128.aspx.

:{> Andy

|||We have also run into this error, and have used the work around of extending our expiration out to 999 days.

Is SP2 close to being released?

thanks,
jg|||

Do subscribers and publishers both need to be upgraded to SP2a for this to be fixed

We upgraded the publisher, and this is still happening.

I'll see if it happens to any of the subscribers after we upgrade them to sp2a.

Bruce

merge agent error

We are using HTTPS merge replication.

One of my subscribers is getting this error:

Error messages:

This is a bit surprising - it has been working fine - and also there were no changes at the publisher (it only has one article in this publication - a stored proc)

Why would this have happened ? The retention period is 45 days and they synchronised successfully only a few days prior.

thanks

1. How often (frequently) does your app do merge between the publisher and this subscriber? If you had other subscribers and have done merge sync, did the same issue raise?

2. What if you select last_sync_date and metadatacleanuptime from sysmergesubscriptions on the publication database?

Thanks.

This posting is provided "AS IS" with no warranties, and confers no rights

|||

Thanks for replying.

1. It syncs up every day

2. last_sync_date = 2006-04-28 21:28:58.803
metadatacleanuptime = 2006-05-02 17:37:25.420

We have a number of clients for whom we setup merge replication. For each database we create two publications

1) the first publication has all the data and procs - it is setup with the syncType set to None. Therefore when we initialise the subscription the subscriber already has the data and schema.

We have noticed that it is the second publication which is often getting this error - even though the clients are regularly synchronising....

Regards
Bruce

|||

Any ideas on this ?

Thanks
Bruce

|||

Also, how many articles are in the other publication?

|||

Thanks for the response - I'm away for the next 5 days so can't get the answer on use_partition_groups yet...

In the other publication - there are about 600 I s'pose - 100 old tables and 500 procs or more.

Is there any way to stop this happening until sp2 ? We are rolling this out at the moment...

Thanks

It syncs every day if the pc is on ! This client turns it off on the weekend.

Yes - use_partition_groups is set to 0 for both publications

In case it matters the subscriptions are setup as follows:

Thanks
Bruce

|||

hi Greg

Any further update on a fix for this ?

Thanks
Bruce

|||

Bruce,

You can wait for Service pack 2 for the fix.

As a workaround, what you can do is increase the retention period of the publications. That way, the possibility of hitting the bug is lesser.

As per your question of reintializing the publication, all subscriptions to the publication you right clicked (and chose reinitialize) will be renitialized. No other publication will be affected.

|||

FYI,

We are having the same issue and are eagerly awaiting SP2 or a hotfix.

|||

We are having a similar issue but it is the other way round.

Any ideas as to why we are getting this problem? Is this a known issue?

|||

I posted a visual guide to addressing this issue at: http://www.vsteamsystemcentral.com/cs/blogs/applied_team_system/archive/2006/08/13/128.aspx.

:{> Andy

|||We have also run into this error, and have used the work around of extending our expiration out to 999 days.

Is SP2 close to being released?

thanks,
jg|||

Do subscribers and publishers both need to be upgraded to SP2a for this to be fixed

We upgraded the publisher, and this is still happening.

I'll see if it happens to any of the subscribers after we upgrade them to sp2a.

Bruce

merge agent error

We are using HTTPS merge replication.

One of my subscribers is getting this error:

Error messages:

This is a bit surprising - it has been working fine - and also there were no changes at the publisher (it only has one article in this publication - a stored proc)

Why would this have happened ? The retention period is 45 days and they synchronised successfully only a few days prior.

thanks

1. How often (frequently) does your app do merge between the publisher and this subscriber? If you had other subscribers and have done merge sync, did the same issue raise?

2. What if you select last_sync_date and metadatacleanuptime from sysmergesubscriptions on the publication database?

Thanks.

This posting is provided "AS IS" with no warranties, and confers no rights

|||

Thanks for replying.

1. It syncs up every day

2. last_sync_date = 2006-04-28 21:28:58.803
metadatacleanuptime = 2006-05-02 17:37:25.420

We have a number of clients for whom we setup merge replication. For each database we create two publications

1) the first publication has all the data and procs - it is setup with the syncType set to None. Therefore when we initialise the subscription the subscriber already has the data and schema.

We have noticed that it is the second publication which is often getting this error - even though the clients are regularly synchronising....

Regards
Bruce

|||

Any ideas on this ?

Thanks
Bruce

|||

Also, how many articles are in the other publication?

|||

Thanks for the response - I'm away for the next 5 days so can't get the answer on use_partition_groups yet...

In the other publication - there are about 600 I s'pose - 100 old tables and 500 procs or more.

Is there any way to stop this happening until sp2 ? We are rolling this out at the moment...

Thanks

It syncs every day if the pc is on ! This client turns it off on the weekend.

Yes - use_partition_groups is set to 0 for both publications

In case it matters the subscriptions are setup as follows:

Thanks
Bruce

|||

hi Greg

Any further update on a fix for this ?

Thanks
Bruce

|||

Bruce,

You can wait for Service pack 2 for the fix.

As a workaround, what you can do is increase the retention period of the publications. That way, the possibility of hitting the bug is lesser.

As per your question of reintializing the publication, all subscriptions to the publication you right clicked (and chose reinitialize) will be renitialized. No other publication will be affected.

|||

FYI,

We are having the same issue and are eagerly awaiting SP2 or a hotfix.

|||

We are having a similar issue but it is the other way round.

Any ideas as to why we are getting this problem? Is this a known issue?

|||

I posted a visual guide to addressing this issue at: http://www.vsteamsystemcentral.com/cs/blogs/applied_team_system/archive/2006/08/13/128.aspx.

:{> Andy

|||We have also run into this error, and have used the work around of extending our expiration out to 999 days.

Is SP2 close to being released?

thanks,
jg

|||

Do subscribers and publishers both need to be upgraded to SP2a for this to be fixed

We upgraded the publisher, and this is still happening.

I'll see if it happens to any of the subscribers after we upgrade them to sp2a.

Bruce

merge agent error

We are using HTTPS merge replication.

One of my subscribers is getting this error:

Error messages:

This is a bit surprising - it has been working fine - and also there were no changes at the publisher (it only has one article in this publication - a stored proc)

Why would this have happened ? The retention period is 45 days and they synchronised successfully only a few days prior.

thanks

1. How often (frequently) does your app do merge between the publisher and this subscriber? If you had other subscribers and have done merge sync, did the same issue raise?

2. What if you select last_sync_date and metadatacleanuptime from sysmergesubscriptions on the publication database?

Thanks.

This posting is provided "AS IS" with no warranties, and confers no rights

|||

Thanks for replying.

1. It syncs up every day

2. last_sync_date = 2006-04-28 21:28:58.803
metadatacleanuptime = 2006-05-02 17:37:25.420

We have a number of clients for whom we setup merge replication. For each database we create two publications

1) the first publication has all the data and procs - it is setup with the syncType set to None. Therefore when we initialise the subscription the subscriber already has the data and schema.

We have noticed that it is the second publication which is often getting this error - even though the clients are regularly synchronising....

Regards
Bruce

|||

Any ideas on this ?

Thanks
Bruce

|||

Also, how many articles are in the other publication?

|||

Thanks for the response - I'm away for the next 5 days so can't get the answer on use_partition_groups yet...

In the other publication - there are about 600 I s'pose - 100 old tables and 500 procs or more.

Is there any way to stop this happening until sp2 ? We are rolling this out at the moment...

Thanks

It syncs every day if the pc is on ! This client turns it off on the weekend.

Yes - use_partition_groups is set to 0 for both publications

In case it matters the subscriptions are setup as follows:

Thanks
Bruce

|||

hi Greg

Any further update on a fix for this ?

Thanks
Bruce

|||

Bruce,

You can wait for Service pack 2 for the fix.

As a workaround, what you can do is increase the retention period of the publications. That way, the possibility of hitting the bug is lesser.

As per your question of reintializing the publication, all subscriptions to the publication you right clicked (and chose reinitialize) will be renitialized. No other publication will be affected.

|||

FYI,

We are having the same issue and are eagerly awaiting SP2 or a hotfix.

|||

We are having a similar issue but it is the other way round.

Any ideas as to why we are getting this problem? Is this a known issue?

|||

I posted a visual guide to addressing this issue at: http://www.vsteamsystemcentral.com/cs/blogs/applied_team_system/archive/2006/08/13/128.aspx.

:{> Andy

|||We have also run into this error, and have used the work around of extending our expiration out to 999 days.

Is SP2 close to being released?

thanks,
jg|||

Do subscribers and publishers both need to be upgraded to SP2a for this to be fixed

We upgraded the publisher, and this is still happening.

I'll see if it happens to any of the subscribers after we upgrade them to sp2a.

Bruce

sql

merge agent error

We are using HTTPS merge replication.

One of my subscribers is getting this error:

Error messages:

This is a bit surprising - it has been working fine - and also there were no changes at the publisher (it only has one article in this publication - a stored proc)

Why would this have happened ? The retention period is 45 days and they synchronised successfully only a few days prior.

thanks

1. How often (frequently) does your app do merge between the publisher and this subscriber? If you had other subscribers and have done merge sync, did the same issue raise?

2. What if you select last_sync_date and metadatacleanuptime from sysmergesubscriptions on the publication database?

Thanks.

This posting is provided "AS IS" with no warranties, and confers no rights

|||

Thanks for replying.

1. It syncs up every day

2. last_sync_date = 2006-04-28 21:28:58.803
metadatacleanuptime = 2006-05-02 17:37:25.420

We have a number of clients for whom we setup merge replication. For each database we create two publications

1) the first publication has all the data and procs - it is setup with the syncType set to None. Therefore when we initialise the subscription the subscriber already has the data and schema.

We have noticed that it is the second publication which is often getting this error - even though the clients are regularly synchronising....

Regards
Bruce

|||

Any ideas on this ?

Thanks
Bruce

|||

Also, how many articles are in the other publication?

|||

Thanks for the response - I'm away for the next 5 days so can't get the answer on use_partition_groups yet...

In the other publication - there are about 600 I s'pose - 100 old tables and 500 procs or more.

Is there any way to stop this happening until sp2 ? We are rolling this out at the moment...

Thanks

It syncs every day if the pc is on ! This client turns it off on the weekend.

Yes - use_partition_groups is set to 0 for both publications

In case it matters the subscriptions are setup as follows:

Thanks
Bruce

|||

hi Greg

Any further update on a fix for this ?

Thanks
Bruce

|||

Bruce,

You can wait for Service pack 2 for the fix.

As a workaround, what you can do is increase the retention period of the publications. That way, the possibility of hitting the bug is lesser.

As per your question of reintializing the publication, all subscriptions to the publication you right clicked (and chose reinitialize) will be renitialized. No other publication will be affected.

|||

FYI,

We are having the same issue and are eagerly awaiting SP2 or a hotfix.

|||

We are having a similar issue but it is the other way round.

Any ideas as to why we are getting this problem? Is this a known issue?

|||

I posted a visual guide to addressing this issue at: http://www.vsteamsystemcentral.com/cs/blogs/applied_team_system/archive/2006/08/13/128.aspx.

:{> Andy

|||We have also run into this error, and have used the work around of extending our expiration out to 999 days.

Is SP2 close to being released?

thanks,
jg

|||

Do subscribers and publishers both need to be upgraded to SP2a for this to be fixed

We upgraded the publisher, and this is still happening.

I'll see if it happens to any of the subscribers after we upgrade them to sp2a.

Bruce

merge agent error

We are using HTTPS merge replication.

One of my subscribers is getting this error:

Error messages:

This is a bit surprising - it has been working fine - and also there were no changes at the publisher (it only has one article in this publication - a stored proc)

Why would this have happened ? The retention period is 45 days and they synchronised successfully only a few days prior.

thanks

1. How often (frequently) does your app do merge between the publisher and this subscriber? If you had other subscribers and have done merge sync, did the same issue raise?

2. What if you select last_sync_date and metadatacleanuptime from sysmergesubscriptions on the publication database?

Thanks.

This posting is provided "AS IS" with no warranties, and confers no rights

|||

Thanks for replying.

1. It syncs up every day

2. last_sync_date = 2006-04-28 21:28:58.803
metadatacleanuptime = 2006-05-02 17:37:25.420

We have a number of clients for whom we setup merge replication. For each database we create two publications

1) the first publication has all the data and procs - it is setup with the syncType set to None. Therefore when we initialise the subscription the subscriber already has the data and schema.

We have noticed that it is the second publication which is often getting this error - even though the clients are regularly synchronising....

Regards
Bruce

|||

Any ideas on this ?

Thanks
Bruce

|||

Also, how many articles are in the other publication?

|||

Thanks for the response - I'm away for the next 5 days so can't get the answer on use_partition_groups yet...

In the other publication - there are about 600 I s'pose - 100 old tables and 500 procs or more.

Is there any way to stop this happening until sp2 ? We are rolling this out at the moment...

Thanks

It syncs every day if the pc is on ! This client turns it off on the weekend.

Yes - use_partition_groups is set to 0 for both publications

In case it matters the subscriptions are setup as follows:

Thanks
Bruce

|||

hi Greg

Any further update on a fix for this ?

Thanks
Bruce

|||

Bruce,

You can wait for Service pack 2 for the fix.

As a workaround, what you can do is increase the retention period of the publications. That way, the possibility of hitting the bug is lesser.

As per your question of reintializing the publication, all subscriptions to the publication you right clicked (and chose reinitialize) will be renitialized. No other publication will be affected.

|||

FYI,

We are having the same issue and are eagerly awaiting SP2 or a hotfix.

|||

We are having a similar issue but it is the other way round.

Any ideas as to why we are getting this problem? Is this a known issue?

|||

I posted a visual guide to addressing this issue at: http://www.vsteamsystemcentral.com/cs/blogs/applied_team_system/archive/2006/08/13/128.aspx.

:{> Andy

|||We have also run into this error, and have used the work around of extending our expiration out to 999 days.

Is SP2 close to being released?

thanks,
jg|||

Do subscribers and publishers both need to be upgraded to SP2a for this to be fixed

We upgraded the publisher, and this is still happening.

I'll see if it happens to any of the subscribers after we upgrade them to sp2a.

Bruce

merge agent error

We are using HTTPS merge replication.

One of my subscribers is getting this error:

Error messages:

This is a bit surprising - it has been working fine - and also there were no changes at the publisher (it only has one article in this publication - a stored proc)

Why would this have happened ? The retention period is 45 days and they synchronised successfully only a few days prior.

thanks

1. How often (frequently) does your app do merge between the publisher and this subscriber? If you had other subscribers and have done merge sync, did the same issue raise?

2. What if you select last_sync_date and metadatacleanuptime from sysmergesubscriptions on the publication database?

Thanks.

This posting is provided "AS IS" with no warranties, and confers no rights

|||

Thanks for replying.

1. It syncs up every day

2. last_sync_date = 2006-04-28 21:28:58.803
metadatacleanuptime = 2006-05-02 17:37:25.420

We have a number of clients for whom we setup merge replication. For each database we create two publications

1) the first publication has all the data and procs - it is setup with the syncType set to None. Therefore when we initialise the subscription the subscriber already has the data and schema.

We have noticed that it is the second publication which is often getting this error - even though the clients are regularly synchronising....

Regards
Bruce

|||

Any ideas on this ?

Thanks
Bruce

|||

Also, how many articles are in the other publication?

|||

Thanks for the response - I'm away for the next 5 days so can't get the answer on use_partition_groups yet...

In the other publication - there are about 600 I s'pose - 100 old tables and 500 procs or more.

Is there any way to stop this happening until sp2 ? We are rolling this out at the moment...

Thanks

It syncs every day if the pc is on ! This client turns it off on the weekend.

Yes - use_partition_groups is set to 0 for both publications

In case it matters the subscriptions are setup as follows:

Thanks
Bruce

|||

hi Greg

Any further update on a fix for this ?

Thanks
Bruce

|||

Bruce,

You can wait for Service pack 2 for the fix.

As a workaround, what you can do is increase the retention period of the publications. That way, the possibility of hitting the bug is lesser.

As per your question of reintializing the publication, all subscriptions to the publication you right clicked (and chose reinitialize) will be renitialized. No other publication will be affected.

|||

FYI,

We are having the same issue and are eagerly awaiting SP2 or a hotfix.

|||

We are having a similar issue but it is the other way round.

Any ideas as to why we are getting this problem? Is this a known issue?

|||

I posted a visual guide to addressing this issue at: http://www.vsteamsystemcentral.com/cs/blogs/applied_team_system/archive/2006/08/13/128.aspx.

:{> Andy

|||We have also run into this error, and have used the work around of extending our expiration out to 999 days.

Is SP2 close to being released?

thanks,
jg

|||

Do subscribers and publishers both need to be upgraded to SP2a for this to be fixed

We upgraded the publisher, and this is still happening.

I'll see if it happens to any of the subscribers after we upgrade them to sp2a.

Bruce

Wednesday, March 28, 2012

merge error rowguidcol

Merge error 2147200925 - why does reboot the server machine could solve problem.

Merge error

merge cannot be performed

Monday, March 26, 2012

Merge Agents Don't "Retry" After SQL Server Error 8645?

merge Agent-login failure

Merge Agent Error: invalid column 'rowguid'

Merge Agent error number 53 for replication

Merge Agent error number 53 for replication

merge agent error

merge agent error

merge agent error

merge agent error

merge agent error

merge agent error

merge agent error

merge agent error

Sql Memory Leaks

Blog Archive

About Me