I have a system where I utilize merge replication between sqlserver2000 and
pocketpc sqlservece 2.0. The setup is very mature, and has been working fine
until I had my customer "refresh" the database with new data. We're still in
the testing phase, and the database I connect to is a copy of their live
one. After the database was restored from a backup of the live database, I
get the following error on the pocketpc when attempting to perform a merge.
Unique indexes and constraints cannot be created on columns that allow null
values
That's as descriptive as the error gets. I have a few questions:
Is there any place either on the server or the pocketpc that I can find a
log with more information. The publication has many articles with many
fields. I can remove one at a time and figure out which one is causing the
problem, but it will take lots of time. I was hoping to find some
information as to which table is causing the problem.
Also I'm having difficulty removing an article from a publication after
subscriptions have been pulled or attempted to be pulled. I've
re-initialized subscriptions, but the articles cannot be removed. What's the
procedure for doing this?
sorry about double post, I got an error message that the first one wasn't
sent!
"mgarner1980" <mgarner@.kbsi.com> wrote in message
news:%23aiSjpAeFHA.3028@.TK2MSFTNGP09.phx.gbl...
> I have a system where I utilize merge replication between sqlserver2000
and
> pocketpc sqlservece 2.0. The setup is very mature, and has been working
fine
> until I had my customer "refresh" the database with new data. We're still
in
> the testing phase, and the database I connect to is a copy of their live
> one. After the database was restored from a backup of the live database, I
> get the following error on the pocketpc when attempting to perform a
merge.
> Unique indexes and constraints cannot be created on columns that allow
null
> values
>
> That's as descriptive as the error gets. I have a few questions:
>
> Is there any place either on the server or the pocketpc that I can find a
> log with more information. The publication has many articles with many
> fields. I can remove one at a time and figure out which one is causing the
> problem, but it will take lots of time. I was hoping to find some
> information as to which table is causing the problem.
>
> Also I'm having difficulty removing an article from a publication after
> subscriptions have been pulled or attempted to be pulled. I've
> re-initialized subscriptions, but the articles cannot be removed. What's
the
> procedure for doing this?
>
Showing posts with label working. Show all posts
Showing posts with label working. Show all posts
Friday, March 30, 2012
Monday, March 26, 2012
Replication Disaster - Help
I had merge replication fully implemented and working beautifully. However,
I recently discovered a 1:many table (tblLoanException) that did not have a
foreign_key constraint created on it. So, I took the following actions:
1. I scripted out the creation of the foreign key constraint on
tblLoanException
2. I ran the script on my publisher to create the fk constraint - success
3. I ran the script on my subscriber via sp_addscriptexec - success
4. I used sp_addmergefilter to create the appropriate merge filter on the
table and it's foreignkey-reference table (tblLoan)
5. I reinitialized the snapshot (reluctantly, but I had to because of the
merge filter add) - success
6. I re-ran the merge agent, which reinitialized my subscriber data set -
success
-- THIS IS WHERE THINGS WENT INTO THE DEPTHS OF HELL
7. The merge agent initialized the subscriber, but then on the next merge
agent run, deleted all but 5 records from the tblLoan table.
8. I ran an "INSERT INTO" the tblLoan table on the publisher to get
backed-up data reinserted
9. Re-ran the merge agent
10. Same thing - merge agent deleted all but 5 additional tblLoan records,
so now I show 10 tblLoan records.
11. Repeats of steps 8 and 9 continue to yield the same results - 5 add'l
tblLoan records get added, but the rest are deleted.
What in the hell have I done here? At this point, I am unable to fix this
problem and have absolutely no idea why 5 records at a time remain in the
tblLoan table, but the rest continue to be deleted. I have several other
1:many filters on the tblLoan table and have had no issues to date. This is
very troubling, to say the least. Any help that can be offered here will be
extremely appreciated. Thanks!
Jeff Jones
Atlanta, GA
What does conflict viewer tell you? I suspect the answer is there. It is
also possible that your filter condition is incorrect. Make sure if you are
using the hostname parameter you over ride it with -HostName or you use a
pull subscription.
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
"J Jones" <JJones@.discussions.microsoft.com> wrote in message
news:B5FCD2B4-D15D-4CDD-94EC-B3BF7C9014DE@.microsoft.com...
>I had merge replication fully implemented and working beautifully.
>However,
> I recently discovered a 1:many table (tblLoanException) that did not have
> a
> foreign_key constraint created on it. So, I took the following actions:
> 1. I scripted out the creation of the foreign key constraint on
> tblLoanException
> 2. I ran the script on my publisher to create the fk constraint - success
> 3. I ran the script on my subscriber via sp_addscriptexec - success
> 4. I used sp_addmergefilter to create the appropriate merge filter on the
> table and it's foreignkey-reference table (tblLoan)
> 5. I reinitialized the snapshot (reluctantly, but I had to because of the
> merge filter add) - success
> 6. I re-ran the merge agent, which reinitialized my subscriber data set -
> success
> -- THIS IS WHERE THINGS WENT INTO THE DEPTHS OF HELL
> 7. The merge agent initialized the subscriber, but then on the next merge
> agent run, deleted all but 5 records from the tblLoan table.
> 8. I ran an "INSERT INTO" the tblLoan table on the publisher to get
> backed-up data reinserted
> 9. Re-ran the merge agent
> 10. Same thing - merge agent deleted all but 5 additional tblLoan
> records,
> so now I show 10 tblLoan records.
> 11. Repeats of steps 8 and 9 continue to yield the same results - 5 add'l
> tblLoan records get added, but the rest are deleted.
> What in the hell have I done here? At this point, I am unable to fix this
> problem and have absolutely no idea why 5 records at a time remain in the
> tblLoan table, but the rest continue to be deleted. I have several other
> 1:many filters on the tblLoan table and have had no issues to date. This
> is
> very troubling, to say the least. Any help that can be offered here will
> be
> extremely appreciated. Thanks!
> Jeff Jones
> Atlanta, GA
|||I receive the following message in the tblLoan conflict table:
The row was inserted at '[PublisherDB.tblLoan]' but could not be inserted at
'[SuscriberDB.tblLoan]'. INSERT statement conflicted with COLUMN FOREIGN KEY
constraint 'FK_Loan_TapeData'. The conflict occurred in database 'ResiDD',
table 'TapeData', column 'LoanID'.
This error makes absolutely no sense to me, as the records that get inserted
into tblLoan have a 1:1 relationship w/TapeData, where the TapeData.LoanID
column is an identity field, but the tblLoan.LoanID is a non-identity column.
The tblLoan records that exist on the publisher do in fact match 1:1 to
what's in the TapeData table on both the publisher and subscriber.
Once the above error occurs, the records get deleted from the
publisher.tblLoan. If I re-insert the remaining TapeData recs into tblLoan,
the merge agent will then insert 5 and only 5 tblLoan records at the
subscriber, and will delete the rest.
The merge agent worked flawlessly until I added the constraint and
mergefilter and re-initialized the snapshot. I've subsequently removed the
constraint and mergefilter and reinitialized the snapshot, but am still
receiving the same error. It just makes no sense at this point that it picks
up five records at a time and then deletes tblLoan records on both the
subscriber and publisher. There is absolutely no foreign key issue in this
scenario. The TapeData recs/keys are identical at both the publisher and
subscriber, and the tblLoan table is set to allow matching TapeData recs to
be added on a 1:1 basis on both the publisher and the subscriber.
I'm beyond frustrated with this...
Jeff
"Hilary Cotter" wrote:
> What does conflict viewer tell you? I suspect the answer is there. It is
> also possible that your filter condition is incorrect. Make sure if you are
> using the hostname parameter you over ride it with -HostName or you use a
> pull subscription.
> --
> 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
>
> "J Jones" <JJones@.discussions.microsoft.com> wrote in message
> news:B5FCD2B4-D15D-4CDD-94EC-B3BF7C9014DE@.microsoft.com...
>
>
|||Also... if I insert the remaining TapeData records into tblLoan on the
SubscriberDB vs. the PublisherDB, the merge agent still only merges 5 recs
from the SubscriberDB.tblLoan back to PublisherDB.tblLoan.
I found a CHECK constraint on the PublisherDB.TapeData table:
([LoanID] > 38548 and [LoanID] < 42000)
The TapeData.LoanIDs on the publisher are within this range.
The CHECK constraint on the SubscriberDB.TapeData table is:
([LoanID] > 51000 and [LoanID] < 54000)
The TapeData records that are on the Subscriber do not fall within the
constraint, but they made it over ok from the publisher.
But, regardless of the CHECK constraint on the TapeData table, the records
that are getting deleted are in the tblLoan table - not the TapeData. Again,
makes no sense to me. I tried altering the CHECK constraint on the
subscriber to make sure that the TapeData records were in range, but still
experienced the same conflict and subsequent deletion of both publisher and
subscriber tblLoan records.
"Hilary Cotter" wrote:
> What does conflict viewer tell you? I suspect the answer is there. It is
> also possible that your filter condition is incorrect. Make sure if you are
> using the hostname parameter you over ride it with -HostName or you use a
> pull subscription.
> --
> 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
>
> "J Jones" <JJones@.discussions.microsoft.com> wrote in message
> news:B5FCD2B4-D15D-4CDD-94EC-B3BF7C9014DE@.microsoft.com...
>
>
I recently discovered a 1:many table (tblLoanException) that did not have a
foreign_key constraint created on it. So, I took the following actions:
1. I scripted out the creation of the foreign key constraint on
tblLoanException
2. I ran the script on my publisher to create the fk constraint - success
3. I ran the script on my subscriber via sp_addscriptexec - success
4. I used sp_addmergefilter to create the appropriate merge filter on the
table and it's foreignkey-reference table (tblLoan)
5. I reinitialized the snapshot (reluctantly, but I had to because of the
merge filter add) - success
6. I re-ran the merge agent, which reinitialized my subscriber data set -
success
-- THIS IS WHERE THINGS WENT INTO THE DEPTHS OF HELL
7. The merge agent initialized the subscriber, but then on the next merge
agent run, deleted all but 5 records from the tblLoan table.
8. I ran an "INSERT INTO" the tblLoan table on the publisher to get
backed-up data reinserted
9. Re-ran the merge agent
10. Same thing - merge agent deleted all but 5 additional tblLoan records,
so now I show 10 tblLoan records.
11. Repeats of steps 8 and 9 continue to yield the same results - 5 add'l
tblLoan records get added, but the rest are deleted.
What in the hell have I done here? At this point, I am unable to fix this
problem and have absolutely no idea why 5 records at a time remain in the
tblLoan table, but the rest continue to be deleted. I have several other
1:many filters on the tblLoan table and have had no issues to date. This is
very troubling, to say the least. Any help that can be offered here will be
extremely appreciated. Thanks!
Jeff Jones
Atlanta, GA
What does conflict viewer tell you? I suspect the answer is there. It is
also possible that your filter condition is incorrect. Make sure if you are
using the hostname parameter you over ride it with -HostName or you use a
pull subscription.
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
"J Jones" <JJones@.discussions.microsoft.com> wrote in message
news:B5FCD2B4-D15D-4CDD-94EC-B3BF7C9014DE@.microsoft.com...
>I had merge replication fully implemented and working beautifully.
>However,
> I recently discovered a 1:many table (tblLoanException) that did not have
> a
> foreign_key constraint created on it. So, I took the following actions:
> 1. I scripted out the creation of the foreign key constraint on
> tblLoanException
> 2. I ran the script on my publisher to create the fk constraint - success
> 3. I ran the script on my subscriber via sp_addscriptexec - success
> 4. I used sp_addmergefilter to create the appropriate merge filter on the
> table and it's foreignkey-reference table (tblLoan)
> 5. I reinitialized the snapshot (reluctantly, but I had to because of the
> merge filter add) - success
> 6. I re-ran the merge agent, which reinitialized my subscriber data set -
> success
> -- THIS IS WHERE THINGS WENT INTO THE DEPTHS OF HELL
> 7. The merge agent initialized the subscriber, but then on the next merge
> agent run, deleted all but 5 records from the tblLoan table.
> 8. I ran an "INSERT INTO" the tblLoan table on the publisher to get
> backed-up data reinserted
> 9. Re-ran the merge agent
> 10. Same thing - merge agent deleted all but 5 additional tblLoan
> records,
> so now I show 10 tblLoan records.
> 11. Repeats of steps 8 and 9 continue to yield the same results - 5 add'l
> tblLoan records get added, but the rest are deleted.
> What in the hell have I done here? At this point, I am unable to fix this
> problem and have absolutely no idea why 5 records at a time remain in the
> tblLoan table, but the rest continue to be deleted. I have several other
> 1:many filters on the tblLoan table and have had no issues to date. This
> is
> very troubling, to say the least. Any help that can be offered here will
> be
> extremely appreciated. Thanks!
> Jeff Jones
> Atlanta, GA
|||I receive the following message in the tblLoan conflict table:
The row was inserted at '[PublisherDB.tblLoan]' but could not be inserted at
'[SuscriberDB.tblLoan]'. INSERT statement conflicted with COLUMN FOREIGN KEY
constraint 'FK_Loan_TapeData'. The conflict occurred in database 'ResiDD',
table 'TapeData', column 'LoanID'.
This error makes absolutely no sense to me, as the records that get inserted
into tblLoan have a 1:1 relationship w/TapeData, where the TapeData.LoanID
column is an identity field, but the tblLoan.LoanID is a non-identity column.
The tblLoan records that exist on the publisher do in fact match 1:1 to
what's in the TapeData table on both the publisher and subscriber.
Once the above error occurs, the records get deleted from the
publisher.tblLoan. If I re-insert the remaining TapeData recs into tblLoan,
the merge agent will then insert 5 and only 5 tblLoan records at the
subscriber, and will delete the rest.
The merge agent worked flawlessly until I added the constraint and
mergefilter and re-initialized the snapshot. I've subsequently removed the
constraint and mergefilter and reinitialized the snapshot, but am still
receiving the same error. It just makes no sense at this point that it picks
up five records at a time and then deletes tblLoan records on both the
subscriber and publisher. There is absolutely no foreign key issue in this
scenario. The TapeData recs/keys are identical at both the publisher and
subscriber, and the tblLoan table is set to allow matching TapeData recs to
be added on a 1:1 basis on both the publisher and the subscriber.
I'm beyond frustrated with this...
Jeff
"Hilary Cotter" wrote:
> What does conflict viewer tell you? I suspect the answer is there. It is
> also possible that your filter condition is incorrect. Make sure if you are
> using the hostname parameter you over ride it with -HostName or you use a
> pull subscription.
> --
> 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
>
> "J Jones" <JJones@.discussions.microsoft.com> wrote in message
> news:B5FCD2B4-D15D-4CDD-94EC-B3BF7C9014DE@.microsoft.com...
>
>
|||Also... if I insert the remaining TapeData records into tblLoan on the
SubscriberDB vs. the PublisherDB, the merge agent still only merges 5 recs
from the SubscriberDB.tblLoan back to PublisherDB.tblLoan.
I found a CHECK constraint on the PublisherDB.TapeData table:
([LoanID] > 38548 and [LoanID] < 42000)
The TapeData.LoanIDs on the publisher are within this range.
The CHECK constraint on the SubscriberDB.TapeData table is:
([LoanID] > 51000 and [LoanID] < 54000)
The TapeData records that are on the Subscriber do not fall within the
constraint, but they made it over ok from the publisher.
But, regardless of the CHECK constraint on the TapeData table, the records
that are getting deleted are in the tblLoan table - not the TapeData. Again,
makes no sense to me. I tried altering the CHECK constraint on the
subscriber to make sure that the TapeData records were in range, but still
experienced the same conflict and subsequent deletion of both publisher and
subscriber tblLoan records.
"Hilary Cotter" wrote:
> What does conflict viewer tell you? I suspect the answer is there. It is
> also possible that your filter condition is incorrect. Make sure if you are
> using the hostname parameter you over ride it with -HostName or you use a
> pull subscription.
> --
> 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
>
> "J Jones" <JJones@.discussions.microsoft.com> wrote in message
> news:B5FCD2B4-D15D-4CDD-94EC-B3BF7C9014DE@.microsoft.com...
>
>
Replication Design, Comments?
Ok, I think I have a working solution. I've worked the past
few days finding a lot of issues (not replication related) which
caused my headaches with replication, ie the @.@.servername was
null, and when creating a stored procedure snapshot it
would complain about unqualified inserts. Learned a neat
trick from Paul on how to do verbose logging. The developers
are looking at their stored procedures.
Merge Replication will be used.
I found that they had used identity columns as primary Key values.
Changed the columns to be 'not for replication'.
Tommorow I will be finding out if they have any DRI (Foreign Key
constraints that need to be marked 'not for replication'.
So far, I've created a Merge publication for the data, and it
appears to be functional.
I have also setup a snapshot publication for the stored procedures.
In addition to having the unqualifed insert issue I made the
mistake of checking 'all sp' instead of just selecting the
stored procedures they created (i was adding the replication
added routines by mistake).
If down the road they change a stored procedure, can I just
reinitialize this subscription to get the up-to-date routines?
I am replicating these because the standby server will be
the live server in case of the primary going offline.
I set the schedule on this subscription(sp) to only run
on demand.
Both machines are on the same backbone, so Bandwidth isn't
an issue.
Since I just found out about the possbible Foreign Key
issue (already created a snapshot, but not the subscription)
I am assuming that I will need to re-do the publication once
the foreign key constraints are marked 'not for replication'?
Thanks for the help. It has been an educational week.
Dave
You will have to drop the pub in order to change it to "not for replication"
(at least if using EM).
"David Gresham" <gresham@.panix.com> wrote in message
news:d5ruoa$6ms$1@.reader1.panix.com...
.....
> Since I just found out about the possbible Foreign Key
> issue (already created a snapshot, but not the subscription)
> I am assuming that I will need to re-do the publication once
> the foreign key constraints are marked 'not for replication'?
|||David,
on the changes to stored procedure point, I'd recommend using transactional
replication, which'll then give you the posibility of using sp_addscriptexec
for a change to a specific SP - and will avoid the need to reinitialize all
procedures.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
few days finding a lot of issues (not replication related) which
caused my headaches with replication, ie the @.@.servername was
null, and when creating a stored procedure snapshot it
would complain about unqualified inserts. Learned a neat
trick from Paul on how to do verbose logging. The developers
are looking at their stored procedures.
Merge Replication will be used.
I found that they had used identity columns as primary Key values.
Changed the columns to be 'not for replication'.
Tommorow I will be finding out if they have any DRI (Foreign Key
constraints that need to be marked 'not for replication'.
So far, I've created a Merge publication for the data, and it
appears to be functional.
I have also setup a snapshot publication for the stored procedures.
In addition to having the unqualifed insert issue I made the
mistake of checking 'all sp' instead of just selecting the
stored procedures they created (i was adding the replication
added routines by mistake).
If down the road they change a stored procedure, can I just
reinitialize this subscription to get the up-to-date routines?
I am replicating these because the standby server will be
the live server in case of the primary going offline.
I set the schedule on this subscription(sp) to only run
on demand.
Both machines are on the same backbone, so Bandwidth isn't
an issue.
Since I just found out about the possbible Foreign Key
issue (already created a snapshot, but not the subscription)
I am assuming that I will need to re-do the publication once
the foreign key constraints are marked 'not for replication'?
Thanks for the help. It has been an educational week.
Dave
You will have to drop the pub in order to change it to "not for replication"
(at least if using EM).
"David Gresham" <gresham@.panix.com> wrote in message
news:d5ruoa$6ms$1@.reader1.panix.com...
.....
> Since I just found out about the possbible Foreign Key
> issue (already created a snapshot, but not the subscription)
> I am assuming that I will need to re-do the publication once
> the foreign key constraints are marked 'not for replication'?
|||David,
on the changes to stored procedure point, I'd recommend using transactional
replication, which'll then give you the posibility of using sp_addscriptexec
for a change to a specific SP - and will avoid the need to reinitialize all
procedures.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Friday, March 23, 2012
replication conflict at deleting
Hello I have a question.
We have a merge replication between 4 servers and it's working fine but we
had a conflict while deleting a record in a master table wich has the
location and product as a key that says :
"The same row was updated at 'servername1.replication' and deleted at
'servername2.replication'. The resolver chose the update as the winner"
It looks like the same record was updated and deleted in a diferent site,
but first it's imposible because every site touches the products of their
own location, the programs that access the database only inserts, updates or
deletes the records of the location where the user logged belongs. Plus
everytime I delete or update or insert a record in this master table we
insert a transaction record for control.
We had the problem and I can see that the user never updated this master
file because I don't have a transaction for update and they deleted the
record but it never got deleted and the problem is that now I have my master
file with records that are not soppoused to be there anymore.
Is there any other reason why this error comes because as I said they never
updated the record and how can I set replication for the deleted as a winner
in every process.
Thanks in advance
Jennyfer
The conflict resolver will give you enough information to accurately identify
the record that is being updated/deleted.
Before you say it is impossible look at these details and compare them.
If the records match then you need to look at your log files and find out
who is deleting and then who is changing this record.
It sounds like replication has discovered an activity that you were not
aware of.
Jim.
"Jennyfer J Barco" wrote:
> Hello I have a question.
> We have a merge replication between 4 servers and it's working fine but we
> had a conflict while deleting a record in a master table wich has the
> location and product as a key that says :
> "The same row was updated at 'servername1.replication' and deleted at
> 'servername2.replication'. The resolver chose the update as the winner"
> It looks like the same record was updated and deleted in a diferent site,
> but first it's imposible because every site touches the products of their
> own location, the programs that access the database only inserts, updates or
> deletes the records of the location where the user logged belongs. Plus
> everytime I delete or update or insert a record in this master table we
> insert a transaction record for control.
> We had the problem and I can see that the user never updated this master
> file because I don't have a transaction for update and they deleted the
> record but it never got deleted and the problem is that now I have my master
> file with records that are not soppoused to be there anymore.
> Is there any other reason why this error comes because as I said they never
> updated the record and how can I set replication for the deleted as a winner
> in every process.
> Thanks in advance
> Jennyfer
>
>
|||Yes I indentify what is the record being deleted and "update" at the same
time and in my log files I have the transaction for delete but not for
update. But I know that replication discovered some how an activity for this
record.
"Jim Breffni" <JimBreffni@.discussions.microsoft.com> wrote in message
news:4C1F2708-5F98-402C-B4D5-2950FB356CF4@.microsoft.com...
> The conflict resolver will give you enough information to accurately
identify[vbcol=seagreen]
> the record that is being updated/deleted.
> Before you say it is impossible look at these details and compare them.
> If the records match then you need to look at your log files and find out
> who is deleting and then who is changing this record.
> It sounds like replication has discovered an activity that you were not
> aware of.
> Jim.
>
> "Jennyfer J Barco" wrote:
we[vbcol=seagreen]
site,[vbcol=seagreen]
their[vbcol=seagreen]
updates or[vbcol=seagreen]
master[vbcol=seagreen]
never[vbcol=seagreen]
winner[vbcol=seagreen]
We have a merge replication between 4 servers and it's working fine but we
had a conflict while deleting a record in a master table wich has the
location and product as a key that says :
"The same row was updated at 'servername1.replication' and deleted at
'servername2.replication'. The resolver chose the update as the winner"
It looks like the same record was updated and deleted in a diferent site,
but first it's imposible because every site touches the products of their
own location, the programs that access the database only inserts, updates or
deletes the records of the location where the user logged belongs. Plus
everytime I delete or update or insert a record in this master table we
insert a transaction record for control.
We had the problem and I can see that the user never updated this master
file because I don't have a transaction for update and they deleted the
record but it never got deleted and the problem is that now I have my master
file with records that are not soppoused to be there anymore.
Is there any other reason why this error comes because as I said they never
updated the record and how can I set replication for the deleted as a winner
in every process.
Thanks in advance
Jennyfer
The conflict resolver will give you enough information to accurately identify
the record that is being updated/deleted.
Before you say it is impossible look at these details and compare them.
If the records match then you need to look at your log files and find out
who is deleting and then who is changing this record.
It sounds like replication has discovered an activity that you were not
aware of.
Jim.
"Jennyfer J Barco" wrote:
> Hello I have a question.
> We have a merge replication between 4 servers and it's working fine but we
> had a conflict while deleting a record in a master table wich has the
> location and product as a key that says :
> "The same row was updated at 'servername1.replication' and deleted at
> 'servername2.replication'. The resolver chose the update as the winner"
> It looks like the same record was updated and deleted in a diferent site,
> but first it's imposible because every site touches the products of their
> own location, the programs that access the database only inserts, updates or
> deletes the records of the location where the user logged belongs. Plus
> everytime I delete or update or insert a record in this master table we
> insert a transaction record for control.
> We had the problem and I can see that the user never updated this master
> file because I don't have a transaction for update and they deleted the
> record but it never got deleted and the problem is that now I have my master
> file with records that are not soppoused to be there anymore.
> Is there any other reason why this error comes because as I said they never
> updated the record and how can I set replication for the deleted as a winner
> in every process.
> Thanks in advance
> Jennyfer
>
>
|||Yes I indentify what is the record being deleted and "update" at the same
time and in my log files I have the transaction for delete but not for
update. But I know that replication discovered some how an activity for this
record.
"Jim Breffni" <JimBreffni@.discussions.microsoft.com> wrote in message
news:4C1F2708-5F98-402C-B4D5-2950FB356CF4@.microsoft.com...
> The conflict resolver will give you enough information to accurately
identify[vbcol=seagreen]
> the record that is being updated/deleted.
> Before you say it is impossible look at these details and compare them.
> If the records match then you need to look at your log files and find out
> who is deleting and then who is changing this record.
> It sounds like replication has discovered an activity that you were not
> aware of.
> Jim.
>
> "Jennyfer J Barco" wrote:
we[vbcol=seagreen]
site,[vbcol=seagreen]
their[vbcol=seagreen]
updates or[vbcol=seagreen]
master[vbcol=seagreen]
never[vbcol=seagreen]
winner[vbcol=seagreen]
Wednesday, March 21, 2012
Replication Best Practice Question: Split Publications
I am working on a replication design and getting closer to implementation. One of my major concerns is maintaining and updating stored procs and/or user defined functions.
The current design is a single publication, including tables, procs and functions (no views yet). All told there are about 686 articles in the publication. The tables are horizontally partitioned using dynamic filters based on the hostname of the subscriber. There are around 50 subscribers. Most will have small databases (< 250 MB). A few (2-3) will have much larger databases. I am mostly concerned that whenever I have to update a proc or function, I have to re-initialize the subscriptions and that pushes a TON of data out over the network and may interrupt service at the subscriber locations.
I see three options for the procs and functions:
1. Include them in the publication with the data tables
2. Place them in a separate (snapshot only) publication
3. Exclude them entirely from replication and maintain them manually
I am starting to lean towards option #2; but I am a bit concerned about maintaining a duplicate set of replication agents for each subscriber.
Any thoughts and/or comments?
Regards,
hmscott
Am I overlooking something? Is there an option that I have not considered?I maintain them manually. All replication does is replace procs, and I can do that without involving replication.|||I maintain them manually. All replication does is replace procs, and I can do that without involving replication.
How many subscribers?|||Ok - I don't really feel qualified on this subject and don't have that much related experience (I use replication to get disparate data sources into one single, read only point rather than the other way round) however you aren't getting much joy so I might as well wade in as not.
I have read a couple of articles that advocate an approach very like point 2. One, as I recall, suggested one publication per article type which does seem a bit over the top. Anway - although this would require administration of more agents it sounds preferable to administering everything manually.
Can I find my sources? Can I buggery - you will just have to take my word for it that I have read at least two articles that suggest this very set up. I will continue hunting through my favourites.|||Pootle -
Thanks for your comments. I'm going to experiment a bit with this approach in the next fiew days.
Is it me, or does it seem that there's a dearth of information on the net regarding SQL replication? I have found a few sites (http://www.replicationanswers.com/Default.asp, http://www.dyessconsulting.com, and a few articles in http://www.sqlservercentral.com), but it just seems that there's not a whole lot of "hard" information (ie, mostly it's a lot of generic stuff with few practical examples).
Thanks again, I'll try to remember to post back with an update as things progress.
Regards,
hmscott|||That is my experience too. I believe Hilary Cotter is extremely knowledgeable and also active on some forum(s) if you really get no joy here.
The current design is a single publication, including tables, procs and functions (no views yet). All told there are about 686 articles in the publication. The tables are horizontally partitioned using dynamic filters based on the hostname of the subscriber. There are around 50 subscribers. Most will have small databases (< 250 MB). A few (2-3) will have much larger databases. I am mostly concerned that whenever I have to update a proc or function, I have to re-initialize the subscriptions and that pushes a TON of data out over the network and may interrupt service at the subscriber locations.
I see three options for the procs and functions:
1. Include them in the publication with the data tables
2. Place them in a separate (snapshot only) publication
3. Exclude them entirely from replication and maintain them manually
I am starting to lean towards option #2; but I am a bit concerned about maintaining a duplicate set of replication agents for each subscriber.
Any thoughts and/or comments?
Regards,
hmscott
Am I overlooking something? Is there an option that I have not considered?I maintain them manually. All replication does is replace procs, and I can do that without involving replication.|||I maintain them manually. All replication does is replace procs, and I can do that without involving replication.
How many subscribers?|||Ok - I don't really feel qualified on this subject and don't have that much related experience (I use replication to get disparate data sources into one single, read only point rather than the other way round) however you aren't getting much joy so I might as well wade in as not.
I have read a couple of articles that advocate an approach very like point 2. One, as I recall, suggested one publication per article type which does seem a bit over the top. Anway - although this would require administration of more agents it sounds preferable to administering everything manually.
Can I find my sources? Can I buggery - you will just have to take my word for it that I have read at least two articles that suggest this very set up. I will continue hunting through my favourites.|||Pootle -
Thanks for your comments. I'm going to experiment a bit with this approach in the next fiew days.
Is it me, or does it seem that there's a dearth of information on the net regarding SQL replication? I have found a few sites (http://www.replicationanswers.com/Default.asp, http://www.dyessconsulting.com, and a few articles in http://www.sqlservercentral.com), but it just seems that there's not a whole lot of "hard" information (ie, mostly it's a lot of generic stuff with few practical examples).
Thanks again, I'll try to remember to post back with an update as things progress.
Regards,
hmscott|||That is my experience too. I believe Hilary Cotter is extremely knowledgeable and also active on some forum(s) if you really get no joy here.
Replication Architecture question - Pull subscriptions on a SQL cluster...
Greetings:
I am working on a replication setup using transactional replication using with pull subscriptions and a separate distributor. The pull subscriptions are located on a SQL cluster using the virtual SQL Server name as the subscriber; when the box fails over, we get an error of missing replication.dlls. Researching further, we found that replication only works on one node of the subscriber.
Any ideas on what we did wrong in the setup?
Thanks,
Lee Everest
www.texas2oo.com/sqlblog
can you check the c:\program files\Microsoft Sql Server\80\com folder to see if the dll's exist there? If not try to copy and register them on the failing node.|||
We could do that, but i'm afraid that after I try to install one, several (or dozens) of others might show up missing, meaning that we didn't install it properly in the first place. The specific error that we get is:
Cannot load the DLL replsetoriginator extended procedure, or one of the DLLs it references. Reason: 126(The specified module could not be found.). The step failed.
I have no idea which DLL this function is located but could probably find out.
|||This is a missing or corrupt dll. When I have encountered these in SQL FTS clusters I have had to copy the dll's to the failed not and reregister them.|||So you are saying that the setup is correct, and that if the box fails over replication should pick right back up?|||A friend of mine responded, below. Apparently replication shouldn’t miss a beat if failover occurs:
Never had this issue before. We are running 4 node clusters (active/active/active/passive) here and we have never had that issue. I'm going to guess it goes back to the install of SQL. I would just copy any missing dll from one node to the other. It sounds like SQL is looking for them so I think you should be safe just to copy them over.
Any thoughts?
|||That depends on the programming mechanism. Sometimes they need to be registered and sometimes they don't. It these dll's contain com compoents they will be, if not a simple file copy will work.Replication Architecture question - Pull subscriptions on a SQL cluster...
Greetings:
I am working on a replication setup using transactional replication using with pull subscriptions and a separate distributor. The pull subscriptions are located on a SQL cluster using the virtual SQL Server name as the subscriber; when the box fails over, we get an error of missing replication.dlls. Researching further, we found that replication only works on one node of the subscriber.
Any ideas on what we did wrong in the setup?
Thanks,
Lee Everest
www.texas2oo.com/sqlblog
can you check the c:\program files\Microsoft Sql Server\80\com folder to see if the dll's exist there? If not try to copy and register them on the failing node.|||
We could do that, but i'm afraid that after I try to install one, several (or dozens) of others might show up missing, meaning that we didn't install it properly in the first place. The specific error that we get is:
Cannot load the DLL replsetoriginator extended procedure, or one of the DLLs it references. Reason: 126(The specified module could not be found.). The step failed.
I have no idea which DLL this function is located but could probably find out.
|||This is a missing or corrupt dll. When I have encountered these in SQL FTS clusters I have had to copy the dll's to the failed not and reregister them.|||So you are saying that the setup is correct, and that if the box fails over replication should pick right back up?|||A friend of mine responded, below. Apparently replication shouldn’t miss a beat if failover occurs:
Never had this issue before. We are running 4 node clusters (active/active/active/passive) here and we have never had that issue. I'm going to guess it goes back to the install of SQL. I would just copy any missing dll from one node to the other. It sounds like SQL is looking for them so I think you should be safe just to copy them over.
Any thoughts?
|||That depends on the programming mechanism. Sometimes they need to be registered and sometimes they don't. It these dll's contain com compoents they will be, if not a simple file copy will work.Tuesday, March 20, 2012
Replication and security..is it really this UNSECURE!
Hi Guys
I need to create an anonymous pull subscription over the Internet.
I've got everything working but I don't want my subscribers to be able
to connect to the publisher/distributor via Enterprise Manager or
ISQLW or anything else for that matter!! Basically they should only
be able to talk to the Publishing SQL Server through replication
methods. How is this achieved?
I'm currently using SQL Security because I don't want an anonymous
subscriber to impersonate my publishers sqlserver agent account, the
agent on the publisher is used for other scheduled tasks that needs
Domain Admin privileges, am I missing something here!!'
Currently I've got it secure-ish. I've used a specific sql account
and given it access in the PAL and removed the guest account from
other DBs, however you cannot remove the guest account from Master or
Msdb and said account must also be a member of the db_owner role. The
most they can do is issue select statements against tables but I think
that is even too much, for instance they can query sysservers which
would allow them to see other subscribers that we do business with.
Even if I use a secure VPN between publisher and subscriber what's to
stop an inquistive subscriber, using the SQL account that I've told
them to use for their subscription, connecting using EM or ISQLW
through the VPN? Surely there must be a way to give ONLY replication
access but nothing else?
Please help!!What type of Replication are you implementing? Snapshot/Transactional or
Merge ?
If they have the data on the Subscriber, there would really be no need to
connect to the Publisher. So, if the users are connecting to the
Subscribing database, that's all they should need.
Are you attempting to restrict access to the Subscribed database?
There isn't a way to restrict access FROM a particular application. So, if
you allow the user to connect to the Server and grant them access to the
database, then they have access from *any* odbc or oledb application.
There isn't a way to restrict this.
Replication works using the accounts designated with the Agents. It
doesn't rely on what permissions the users have.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
I need to create an anonymous pull subscription over the Internet.
I've got everything working but I don't want my subscribers to be able
to connect to the publisher/distributor via Enterprise Manager or
ISQLW or anything else for that matter!! Basically they should only
be able to talk to the Publishing SQL Server through replication
methods. How is this achieved?
I'm currently using SQL Security because I don't want an anonymous
subscriber to impersonate my publishers sqlserver agent account, the
agent on the publisher is used for other scheduled tasks that needs
Domain Admin privileges, am I missing something here!!'
Currently I've got it secure-ish. I've used a specific sql account
and given it access in the PAL and removed the guest account from
other DBs, however you cannot remove the guest account from Master or
Msdb and said account must also be a member of the db_owner role. The
most they can do is issue select statements against tables but I think
that is even too much, for instance they can query sysservers which
would allow them to see other subscribers that we do business with.
Even if I use a secure VPN between publisher and subscriber what's to
stop an inquistive subscriber, using the SQL account that I've told
them to use for their subscription, connecting using EM or ISQLW
through the VPN? Surely there must be a way to give ONLY replication
access but nothing else?
Please help!!What type of Replication are you implementing? Snapshot/Transactional or
Merge ?
If they have the data on the Subscriber, there would really be no need to
connect to the Publisher. So, if the users are connecting to the
Subscribing database, that's all they should need.
Are you attempting to restrict access to the Subscribed database?
There isn't a way to restrict access FROM a particular application. So, if
you allow the user to connect to the Server and grant them access to the
database, then they have access from *any* odbc or oledb application.
There isn't a way to restrict this.
Replication works using the accounts designated with the Agents. It
doesn't rely on what permissions the users have.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
Replication and security..is it really this UNSECURE!
Hi Guys
I need to create an anonymous pull subscription over the Internet.
I've got everything working but I don't want my subscribers to be able
to connect to the publisher/distributor via Enterprise Manager or
ISQLW or anything else for that matter!! Basically they should only
be able to talk to the Publishing SQL Server through replication
methods. How is this achieved?
I'm currently using SQL Security because I don't want an anonymous
subscriber to impersonate my publishers sqlserver agent account, the
agent on the publisher is used for other scheduled tasks that needs
Domain Admin privileges, am I missing something here!!?
Currently I've got it secure-ish. I've used a specific sql account
and given it access in the PAL and removed the guest account from
other DBs, however you cannot remove the guest account from Master or
Msdb and said account must also be a member of the db_owner role. The
most they can do is issue select statements against tables but I think
that is even too much, for instance they can query sysservers which
would allow them to see other subscribers that we do business with.
Even if I use a secure VPN between publisher and subscriber what's to
stop an inquistive subscriber, using the SQL account that I've told
them to use for their subscription, connecting using EM or ISQLW
through the VPN? Surely there must be a way to give ONLY replication
access but nothing else?
Please help!!
The problem is not with replication and security, but rather a larger one
with SQL Server security in general. Anytime you create an account on that
server, and give that account rights to only one user database, this account
can query system tables on the master database.
I suggest you post this question to the microsoft.public.sqlserver.security
newsgroup.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"greedo" <d8rrylf@.msn.com> wrote in message
news:f0badc7a.0408170010.47baef00@.posting.google.c om...
> Hi Guys
> I need to create an anonymous pull subscription over the Internet.
> I've got everything working but I don't want my subscribers to be able
> to connect to the publisher/distributor via Enterprise Manager or
> ISQLW or anything else for that matter!! Basically they should only
> be able to talk to the Publishing SQL Server through replication
> methods. How is this achieved?
> I'm currently using SQL Security because I don't want an anonymous
> subscriber to impersonate my publishers sqlserver agent account, the
> agent on the publisher is used for other scheduled tasks that needs
> Domain Admin privileges, am I missing something here!!?
> Currently I've got it secure-ish. I've used a specific sql account
> and given it access in the PAL and removed the guest account from
> other DBs, however you cannot remove the guest account from Master or
> Msdb and said account must also be a member of the db_owner role. The
> most they can do is issue select statements against tables but I think
> that is even too much, for instance they can query sysservers which
> would allow them to see other subscribers that we do business with.
> Even if I use a secure VPN between publisher and subscriber what's to
> stop an inquistive subscriber, using the SQL account that I've told
> them to use for their subscription, connecting using EM or ISQLW
> through the VPN? Surely there must be a way to give ONLY replication
> access but nothing else?
> Please help!!
I need to create an anonymous pull subscription over the Internet.
I've got everything working but I don't want my subscribers to be able
to connect to the publisher/distributor via Enterprise Manager or
ISQLW or anything else for that matter!! Basically they should only
be able to talk to the Publishing SQL Server through replication
methods. How is this achieved?
I'm currently using SQL Security because I don't want an anonymous
subscriber to impersonate my publishers sqlserver agent account, the
agent on the publisher is used for other scheduled tasks that needs
Domain Admin privileges, am I missing something here!!?
Currently I've got it secure-ish. I've used a specific sql account
and given it access in the PAL and removed the guest account from
other DBs, however you cannot remove the guest account from Master or
Msdb and said account must also be a member of the db_owner role. The
most they can do is issue select statements against tables but I think
that is even too much, for instance they can query sysservers which
would allow them to see other subscribers that we do business with.
Even if I use a secure VPN between publisher and subscriber what's to
stop an inquistive subscriber, using the SQL account that I've told
them to use for their subscription, connecting using EM or ISQLW
through the VPN? Surely there must be a way to give ONLY replication
access but nothing else?
Please help!!
The problem is not with replication and security, but rather a larger one
with SQL Server security in general. Anytime you create an account on that
server, and give that account rights to only one user database, this account
can query system tables on the master database.
I suggest you post this question to the microsoft.public.sqlserver.security
newsgroup.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"greedo" <d8rrylf@.msn.com> wrote in message
news:f0badc7a.0408170010.47baef00@.posting.google.c om...
> Hi Guys
> I need to create an anonymous pull subscription over the Internet.
> I've got everything working but I don't want my subscribers to be able
> to connect to the publisher/distributor via Enterprise Manager or
> ISQLW or anything else for that matter!! Basically they should only
> be able to talk to the Publishing SQL Server through replication
> methods. How is this achieved?
> I'm currently using SQL Security because I don't want an anonymous
> subscriber to impersonate my publishers sqlserver agent account, the
> agent on the publisher is used for other scheduled tasks that needs
> Domain Admin privileges, am I missing something here!!?
> Currently I've got it secure-ish. I've used a specific sql account
> and given it access in the PAL and removed the guest account from
> other DBs, however you cannot remove the guest account from Master or
> Msdb and said account must also be a member of the db_owner role. The
> most they can do is issue select statements against tables but I think
> that is even too much, for instance they can query sysservers which
> would allow them to see other subscribers that we do business with.
> Even if I use a secure VPN between publisher and subscriber what's to
> stop an inquistive subscriber, using the SQL account that I've told
> them to use for their subscription, connecting using EM or ISQLW
> through the VPN? Surely there must be a way to give ONLY replication
> access but nothing else?
> Please help!!
Wednesday, March 7, 2012
replication - agent is suspect
I setup a client with merge replication, the following error was
returned after working successfully for a day "The agent is suspect.
No response within the last 10 minutes". Most research I found on
the newsgroup is this error does not stop merge replication from
working, but in my case it did stop replication from working. I was
able to get to working again by running the following command.
sp_replication_agent_checkup @.heartbeat_interval = 6000
Can anybody explain why replication stopped working altogether with the
agent is suspect message, and what can I do to avoid this message to
begin with?
Thank you,
Pauly C
Suspect means that the agent hasn't communicated with the job subsystem in
the interval defined in the heartbeat_interval.
The job will be failed after the heartbeat_interval has passed, but I am not
exactly sure when.
The agent could be busy, dead, or trying to connect. Run profiler on the
subscriber to try to figure out what is going on. Profiler might not reveal
anything. There is a condition when the publisher or subscriber has
exhausted buffers and hangs on initialization. You can clear this by
rebooting.
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
"paulysc" <paulysc@.optonline.net> wrote in message
news:1141228700.833217.245870@.t39g2000cwt.googlegr oups.com...
>I setup a client with merge replication, the following error was
> returned after working successfully for a day "The agent is suspect.
> No response within the last 10 minutes". Most research I found on
> the newsgroup is this error does not stop merge replication from
> working, but in my case it did stop replication from working. I was
> able to get to working again by running the following command.
> sp_replication_agent_checkup @.heartbeat_interval = 6000
> Can anybody explain why replication stopped working altogether with the
> agent is suspect message, and what can I do to avoid this message to
> begin with?
> Thank you,
> Pauly C
>
|||I saw this error message if the job runs against a wrong database. In my
case, the Queue Reader was running against the master database, not the
distribution, which resulted to the same error message as yours.
hope it helps,
FJY
"paulysc" wrote:
> I setup a client with merge replication, the following error was
> returned after working successfully for a day "The agent is suspect.
> No response within the last 10 minutes". Most research I found on
> the newsgroup is this error does not stop merge replication from
> working, but in my case it did stop replication from working. I was
> able to get to working again by running the following command.
> sp_replication_agent_checkup @.heartbeat_interval = 6000
> Can anybody explain why replication stopped working altogether with the
> agent is suspect message, and what can I do to avoid this message to
> begin with?
> Thank you,
> Pauly C
>
returned after working successfully for a day "The agent is suspect.
No response within the last 10 minutes". Most research I found on
the newsgroup is this error does not stop merge replication from
working, but in my case it did stop replication from working. I was
able to get to working again by running the following command.
sp_replication_agent_checkup @.heartbeat_interval = 6000
Can anybody explain why replication stopped working altogether with the
agent is suspect message, and what can I do to avoid this message to
begin with?
Thank you,
Pauly C
Suspect means that the agent hasn't communicated with the job subsystem in
the interval defined in the heartbeat_interval.
The job will be failed after the heartbeat_interval has passed, but I am not
exactly sure when.
The agent could be busy, dead, or trying to connect. Run profiler on the
subscriber to try to figure out what is going on. Profiler might not reveal
anything. There is a condition when the publisher or subscriber has
exhausted buffers and hangs on initialization. You can clear this by
rebooting.
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
"paulysc" <paulysc@.optonline.net> wrote in message
news:1141228700.833217.245870@.t39g2000cwt.googlegr oups.com...
>I setup a client with merge replication, the following error was
> returned after working successfully for a day "The agent is suspect.
> No response within the last 10 minutes". Most research I found on
> the newsgroup is this error does not stop merge replication from
> working, but in my case it did stop replication from working. I was
> able to get to working again by running the following command.
> sp_replication_agent_checkup @.heartbeat_interval = 6000
> Can anybody explain why replication stopped working altogether with the
> agent is suspect message, and what can I do to avoid this message to
> begin with?
> Thank you,
> Pauly C
>
|||I saw this error message if the job runs against a wrong database. In my
case, the Queue Reader was running against the master database, not the
distribution, which resulted to the same error message as yours.
hope it helps,
FJY
"paulysc" wrote:
> I setup a client with merge replication, the following error was
> returned after working successfully for a day "The agent is suspect.
> No response within the last 10 minutes". Most research I found on
> the newsgroup is this error does not stop merge replication from
> working, but in my case it did stop replication from working. I was
> able to get to working again by running the following command.
> sp_replication_agent_checkup @.heartbeat_interval = 6000
> Can anybody explain why replication stopped working altogether with the
> agent is suspect message, and what can I do to avoid this message to
> begin with?
> Thank you,
> Pauly C
>
Replication
I was working on a project that use local and remote SQL server. In order to keep the database up-to-date I wanted to implement replication on the SQL servers. But unfortunately thetransaction replication which meet my requirement best is disabled on the replication configuration module (snapshoot and merge replications are active). Is there any way I can make the transaction replication enabled. I know it was supposed to be enabled by default. I’m using Windows 2003 server and SQL server 2000.
Sincerely
Do you mean you can't select the Transactional Replication as Replication Type when configure Publication?|||Yes, that is what i mean.|||Sorry I haven't heard of such issue. If you have no better choice, you may reinstall the client tools to see whether it helps.
Replication
Hi everybody.
I am working on merge replication first time and I ran a
synchronizing processing and get error message:
Cannot insert the value NULL into column 'objid',
table 'ReplicationDB_1.dbo.sysmergeschemaarticles';
column does not allow nulls. INSERT fails.
My snapshots has created successfully.
Any suggestions or advices?
Thank you Mike.
I believe this is a bug. Contact PSS for a hot fix.
"Mike" <anonymous@.discussions.microsoft.com> wrote in message
news:8bbf01c432aa$26749460$a001280a@.phx.gbl...
> Hi everybody.
> I am working on merge replication first time and I ran a
> synchronizing processing and get error message:
> Cannot insert the value NULL into column 'objid',
> table 'ReplicationDB_1.dbo.sysmergeschemaarticles';
> column does not allow nulls. INSERT fails.
> My snapshots has created successfully.
> Any suggestions or advices?
> Thank you Mike.
>
>
I am working on merge replication first time and I ran a
synchronizing processing and get error message:
Cannot insert the value NULL into column 'objid',
table 'ReplicationDB_1.dbo.sysmergeschemaarticles';
column does not allow nulls. INSERT fails.
My snapshots has created successfully.
Any suggestions or advices?
Thank you Mike.
I believe this is a bug. Contact PSS for a hot fix.
"Mike" <anonymous@.discussions.microsoft.com> wrote in message
news:8bbf01c432aa$26749460$a001280a@.phx.gbl...
> Hi everybody.
> I am working on merge replication first time and I ran a
> synchronizing processing and get error message:
> Cannot insert the value NULL into column 'objid',
> table 'ReplicationDB_1.dbo.sysmergeschemaarticles';
> column does not allow nulls. INSERT fails.
> My snapshots has created successfully.
> Any suggestions or advices?
> Thank you Mike.
>
>
Subscribe to:
Posts (Atom)