Showing posts with label successfully. Show all posts
Showing posts with label successfully. Show all posts

Friday, March 23, 2012

replication conflict error.. how to add datas to publisher ....

Hi..

I have configured publisher, distributer,subscriber... and tried to replicate it... it has done successfully...

When i try to add datas to the publisher ... it says

"conflict error"

can you please tell me how to check the replication is successfull or not.

and i want to add datas to publisher so that it should frequently updated in subscriber...

You should start by reading Books Online topic "How Merge Replication Detects and Resolves Conflicts". You can also read Replication topics about merge replication in general to get a better undestanding about how it works and how it's best used.sql

Wednesday, March 21, 2012

Replication between 4 servers

Hello,
Currently I have successfully replicated data between 2
servers. The replication is for the most part stable but
does have its "issues" from time to time.I am still in the
process of understanding all situations that could cause
replication to error out.
Anyhow.. Whewww.. I am now in the position that I need to
replicate this data to 2 other servers.
My question is:
If replication occurs between SERVERA, SERVERB SERVERC
SERVERD.Lets say SERVERA replicates to SERVER B and
SERVERC but the replication fails between SERVERA and
SERVERC. Does the replication subscription I set up
between SERVERA and SERVERB also error out?
Sorry this is long winded.
Thanks,
niv
niv,
Not unless the cause of the replication failure between SERVER A and SERVER
C was caused by a network/hardware failure and the subscription on SERVER B
also relies on these resources. As long as the Log Reader and Distribution
agent is running as well as SERVER C and network connectivity is present it
should be fine.
This really is a broad question. I understand that you would like to cover
all possible scenarios and to ask you to be more specific would not be
relevant.
Charles Deaton
"niv" <niv@.hotmail.com> wrote in message
news:1b3c701c44fb3$e2c83b50$a401280a@.phx.gbl...
> Hello,
> Currently I have successfully replicated data between 2
> servers. The replication is for the most part stable but
> does have its "issues" from time to time.I am still in the
> process of understanding all situations that could cause
> replication to error out.
> Anyhow.. Whewww.. I am now in the position that I need to
> replicate this data to 2 other servers.
> My question is:
> If replication occurs between SERVERA, SERVERB SERVERC
> SERVERD.Lets say SERVERA replicates to SERVER B and
> SERVERC but the replication fails between SERVERA and
> SERVERC. Does the replication subscription I set up
> between SERVERA and SERVERB also error out?
> Sorry this is long winded.
> Thanks,
> niv
|||For transactional, there will either be one Distribution Agent per
subscription (an independent agent) or one Distribution Agent per
publication database and subscription database pair (a shared agent). For
merge, each merge subscription has its own Merge Agent that connects to and
updates both the Publisher and the Subscriber. So, as the agents in your
case are independant, a failure in one will not affect the other in a sense
of the replication process. However, as Charles points out, if the error is
a general one to your network then both agents will fail.
HTH,
Paul Ibison

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
>

Saturday, February 25, 2012

Replication

undefined

Hi,

I have successfully replicated a database (type : Transactional), but when i have executed a Alter scripts to effect the schema of the database it worked. My concern is whether the replication was done successfully or not ?
Can we change the schema of a replicated database by plain Alter scripts ?
Plz let me know....

Thanks
RakeshDepending on what you altered. If you want to alter rules or foreign keys without checking replication, you don't have to do anything to the replication setup. But if you change table schma, you need to either use the replication system procedures to change it or you have to drop all subscriptions and initialize them.|||I am able to alter the table schema by using Replication stored procedures, but my concern is, i am also able to change the table schema by simple alter statements on the primary database, but these changes are not making into secondary database i,e subscriber database. Do we get any error Msg trying to alter a table schema of a replicated database ?|||Yes, you should get an error messge when you try to use an ALTER TABLE command against a replicated table. The ALTER TABLE should fail, but it sounds like it is working for you.

Is it possible that the table you are affecting isn't being replicated (either it was never included in a publication, or that its article has been dropped from the publication)?

-PatP|||Yes, you should get an error messge when you try to use an ALTER TABLE command against a replicated table. The ALTER TABLE should fail, but it sounds like it is working for you.

Is it possible that the table you are affecting isn't being replicated (either it was never included in a publication, or that its article has been dropped from the publication)?

-PatP

In case of merge replication it is not possible to alter repilcated table but for transaction replication it works. Welcome to Microsoft...

Monday, February 20, 2012

Replicating ORACLE views?

I have successfully replicated ORACLE tables to a SQL Server, however
I don't see ORACLE views listed in the "Articles" dialog when I open
the ORACLE publication properties.
Is this because it is not possible to replicate ORACLE views or am i
missing something?
TIA
This is not supported for Oracle publishers - pls take a look at
sp_addarticle (http://msdn2.microsoft.com/en-us/library/ms173857.aspx)
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||Hi,
I am trying to setup transactional replication between an Oracle DB (one
table - that too few of the columns) and SQL Server 2005. Can you please
point me to an article or web page where I can get some instructions. I have
followed the step in BOL and getting nowhere. Your help will be much
appreciated.
Thank you,
Yoga
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uw28PlTUHHA.1016@.TK2MSFTNGP04.phx.gbl...
> This is not supported for Oracle publishers - pls take a look at
> sp_addarticle (http://msdn2.microsoft.com/en-us/library/ms173857.aspx)
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
>
|||I know Andrew Carter was looking for people using the functionality to work
with a while back
(http://blogs.msdn.com/ascarter/archive/2004/08/05/209056.aspx) - might be
worth contacting him. There's also a webcast:
http://whitepapers.techrepublic.com.com/whitepaper.aspx?docid=149653. Apart
from that I think Sujoy Paul's Replication book has a section on setting it
up as far as I recall.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com