Showing posts with label sql2005. Show all posts
Showing posts with label sql2005. Show all posts

Friday, March 30, 2012

Merge sinchronization problem

Hi there.

I have big problem with SQL2005 merge sinchronization from single subscriber. This problem reveals itself on one database publications (it worked till today fine) but not others. Sincronization job writes to histrory :

The merge process was unable to create a new generation at the 'Subscriber'. Troubleshoot by restarting the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147200994).

This message can be found in sincronization status after 30 minutes idle with status

Upload changes to publisher

During this time the replication agent job locks another one. I think subscriber can not upload changes from subscriber, which have accumulated them since sinchronization failure start.

How can I log verbose history to file?

Will be appreciate for help.

Here is the info how to logging...

How to enable replication agents for logging to output files in SQL Server

http://support.microsoft.com/kb/312292

|||Did you ever find a solution to the problem. I have had the same error on a couple of different subscribers and the verbose logging does not show where the problem is!

?

Thanks

Stuart

|||

I am also experiencing similar problems.

In my case, we are using pull subscriptions from 24 different subscribers all to one published database. Distributor is same as publisher.

No answers yet, but we're getting MS help on it -- sort of. Very difficult to track down without being able to get useful data, and getting useful data is proving to be difficult.

Merge sinchronization problem

Hi there.

I have big problem with SQL2005 merge sinchronization from single subscriber. This problem reveals itself on one database publications (it worked till today fine) but not others. Sincronization job writes to histrory :

The merge process was unable to create a new generation at the 'Subscriber'. Troubleshoot by restarting the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147200994).

This message can be found in sincronization status after 30 minutes idle with status

Upload changes to publisher

During this time the replication agent job locks another one. I think subscriber can not upload changes from subscriber, which have accumulated them since sinchronization failure start.

How can I log verbose history to file?

Will be appreciate for help.

Here is the info how to logging...

How to enable replication agents for logging to output files in SQL Server

http://support.microsoft.com/kb/312292

|||Did you ever find a solution to the problem. I have had the same error on a couple of different subscribers and the verbose logging does not show where the problem is!

?

Thanks

Stuart

|||

I am also experiencing similar problems.

In my case, we are using pull subscriptions from 24 different subscribers all to one published database. Distributor is same as publisher.

No answers yet, but we're getting MS help on it -- sort of. Very difficult to track down without being able to get useful data, and getting useful data is proving to be difficult.

Merge seems to hang at conflict and conflict is not logged

We have a SQL2005 merge replication database with 8 subscribers. Three of the
subscribers have not successfully replicated. We would appreciate any
additional ideas for correcting this. So far we have some inconsistencies.
For example, the "View Synchronization Status" displays:
"Downloaded 100 change(s) in 'OurTable' (100 updates, 1 conflict)"
and the publisher's "Microsoft Replication Conflict Viewer" displays:
"There are no conflicts to view."
If you have any ideas why conflicts are causing the replication to fail
while the conflict viewer shows no conflicts, we would appreciate your input.
Thanx.
Were there any conflicts on the subscriber side?
You can run the conflict viewer there as well, or if that's not
convenient/possible there are sp_xxx procedures to help you view the
conflict tables on the client...

Friday, March 23, 2012

Merge replication row filter

I have a situation which I can't seem to find an answer to. I have
merge replication set up in SQL2005 and everything seems to work find
except that the row filter for a table isn't working 100%. I have 200
or so field guys who have SQL Express installed on their laptops who
syncronize data back to the server through web syncronization. The
filter in question looks like this:
SELECT <published columns> FROM [dbo].[Stores]
WHERE Division =
(SELECT DivID FROM Divisions
WHERE DistrictDivision = HOST_NAME())
The row filter works fine except when a store is moved from one
division to the next. While it shows up in the new division, it
remains in the old one. I have tested the select statements used in
the filter and they return act as expected. Has anyone seen anything
like this?
Thanks in advance
JC
Hi,
On SQL2005 there is a parameter to sp_addmergepublication called
@.allow_partition_realignment. It sounds like the option you need if
you want to remove a store from the old division. You may need to
consider realigning your current subscribers by forcing a
reinitialisation.
http://msdn2.microsoft.com/en-us/library/ms176103.aspx
Tim
On Mar 31, 6:07 pm, "JC" <jbzcoo...@.gmail.com> wrote:
> I have a situation which I can't seem to find an answer to. I have
> merge replication set up in SQL2005 and everything seems to work find
> except that the row filter for a table isn't working 100%. I have 200
> or so field guys who have SQL Express installed on their laptops who
> syncronize data back to the server through web syncronization. The
> filter in question looks like this:
> SELECT <published columns> FROM [dbo].[Stores]
> WHERE Division =
> (SELECT DivID FROM Divisions
> WHERE DistrictDivision = HOST_NAME())
> The row filter works fine except when a store is moved from one
> division to the next. While it shows up in the new division, it
> remains in the old one. I have tested the select statements used in
> the filter and they return act as expected. Has anyone seen anything
> like this?
> Thanks in advance
> JC

Merge replication reinitialization deleted all data

Hello,

When I reinitialized a subscription from SQL2005 db (publisher) to a SQL 2000 DB (Subscriber) and had the Upload changes before reinitialization turned on, the data from the SQL 2000 db didn't get uploaded. This resulted in a loss of 2 days worth of data.

Does anyone have any idea if there's anywhere that data is kept. (unfortunately a series of errors caused our backups to not be running on the 2000 db either).

Thank You

Bob

sorry, your data is gone. I also find it hard to believe your data didn't get uploaded - how did you indicate you wanted the data uploaded? Was this reinitialized from the UI?|||

Yes it was from the UI and the box marked "Upload data before reinitialization" was checked.

|||

I could not reproduce the problem.

I tried push and pull SQL 200 subscriptions from a SQL 2005 publication/pulisher.

Could you give me more details on what kind of subscription you have and the SP of SQL you are running on both the servers?

Also can you continue to reproduce this? If so, some more details and some steps would be of help.

Wednesday, March 7, 2012

Merge Replication doesn't re-propagate changes coming from transactional replication

Hi,
I have the following setup:
OracleDB
SQL2005
SQL2005Express
There's a transactional replication between OracleDB and SQL2005; and there's
a merge replication between SQL2005 and SQL2005Express.
Changes made in OracleDB properly synchronized into SQL2005, but for some
reason Merge Replication does not recognize them (so after synchronization
SQL2005Express doesn't receive those changes). Please note that if I'm inserting/updating
SQL2005 directly, the changes are properly synchronized to SQL2005Express
- so merge replication setup is OK...
Please help,
Vladimir Kofman.
Hi,
If anyone interested I just found the answer at http://msdn2.microsoft.com/en-us/library/ms152559.aspx
:
"If an article is published in a transactional publication and a merge publication,
ensure that the @.published_in_tran_pub property is set to TRUE for the merge
article" - I tried it, and it indeed did the trick!
Vladimir Kofman

> Hi,
> I have the following setup:
> OracleDB
> SQL2005
> SQL2005Express
> There's a transactional replication between OracleDB and SQL2005; and
> there's
> a merge replication between SQL2005 and SQL2005Express.
> Changes made in OracleDB properly synchronized into SQL2005, but for
> some
> reason Merge Replication does not recognize them (so after
> synchronization
> SQL2005Express doesn't receive those changes). Please note that if I'm
> inserting/updating
> SQL2005 directly, the changes are properly synchronized to
> SQL2005Express
> - so merge replication setup is OK...
> Please help,
> Vladimir Kofman.

Saturday, February 25, 2012

merge replication compatibility issue

All,
I have a SQL2005 server that is running merge replication against SQL2000
boxes. One of my SQL2000 box needed to be replaced due to disk issues. I
scripted out my Subscription from my 2005 box and tried to reapply it after I
rebuilt my new 2000 box. When I run the script I get an error saying:
"Publication 'PubName' cannot be added to database 'DBNAme', because a
publication with a higher compatibility level already exists. All merge
publications in a database must have the same compatibiliy level."
I am in the process of upgrading all my 2000 boxes, but this one, since i
was having issues I wanted to get it back to its original state before
upgrading it.
Right now there is a mix of replications running pointing to a few SQl2000
and Some SQL2005.
Is there a way to get around this before upgrading my new box to 2005?
TIA,
John
Similar, but what I had to do was to change the compatibilty level of all my
subscriptions to 2005 and I was able to add this new one back in.
Thanks for the response.
"Paul Ibison" wrote:

> Is this related to your issue:
> [url]http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.sqlserver.replica tion&tid=4e5d642b-a4c0-4574-8bae-98fcc88e19b8&p=1[/url]
> IE I'm wondering if you have a republishing setup.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
>
>
|||John,
I had very similar situation just the other day, where somebody deleted
publication on SQL2000's level while
there were some pubs already created in 2005's level and I needed to
recreate the publication.
I somehow managed to fix it, but I'm afraid I might have lost some
unsynchronized data in the process - I'm not sure it was the best way to do
it. Could you post step by step description how did you handle it?
thanks,
r
"jaylou" <jaylou@.discussions.microsoft.com> wrote in message
news:C284873D-DD99-45A5-A191-047EE33E004E@.microsoft.com...[vbcol=seagreen]
> Similar, but what I had to do was to change the compatibilty level of all
> my
> subscriptions to 2005 and I was able to add this new one back in.
> Thanks for the response.
> "Paul Ibison" wrote:
|||I scrpited out my replication as a delete and create.
I ran the delete with no issues, but when I tried to run the create that's
when I fell into the compatibilty issue.
i changed all the SQL 200 compatibity levels to 2005 and changed my script
from 80rtm to 90rtm on the create statement of the script SQl generated.
I reran the create and it created with no issues. I started my agent and
synced my data since I only care about what happens here in my main office
anything changed at my branch got overwritten if there were any changes at
both places.
Is that the same way you did yours? maybe you had a better solution, mine
seemed to work for me but I am always looking for better and different
solutions.
"Rafael Lenartowicz" wrote:

> John,
> I had very similar situation just the other day, where somebody deleted
> publication on SQL2000's level while
> there were some pubs already created in 2005's level and I needed to
> recreate the publication.
> I somehow managed to fix it, but I'm afraid I might have lost some
> unsynchronized data in the process - I'm not sure it was the best way to do
> it. Could you post step by step description how did you handle it?
> thanks,
> r
> "jaylou" <jaylou@.discussions.microsoft.com> wrote in message
> news:C284873D-DD99-45A5-A191-047EE33E004E@.microsoft.com...
>
>
|||how did you manage to change the compatibility level? using
sp_changemergepublication ?
I wasn't able to do it, it was complaining something about the incompatible
snapshot...
besides - in my setup the data from the remote location IS the vital data -
they submiting their
daily revenue reports to the central office reporting server, I can't have
anything overwritten or lost.
thanks
r
"jaylou" <jaylou@.discussions.microsoft.com> wrote in message
news:EE97BCC9-6445-44F4-BF33-D115DDD98B43@.microsoft.com...[vbcol=seagreen]
>I scrpited out my replication as a delete and create.
> I ran the delete with no issues, but when I tried to run the create that's
> when I fell into the compatibilty issue.
> i changed all the SQL 200 compatibity levels to 2005 and changed my script
> from 80rtm to 90rtm on the create statement of the script SQl generated.
> I reran the create and it created with no issues. I started my agent and
> synced my data since I only care about what happens here in my main office
> anything changed at my branch got overwritten if there were any changes at
> both places.
> Is that the same way you did yours? maybe you had a better solution, mine
> seemed to work for me but I am always looking for better and different
> solutions.
> "Rafael Lenartowicz" wrote: