How to remove replication?

Hi, all.
I have two server(Svr01, Svr02) that are replicated each other (Merge replication).
Svr01 must be Publisher distributor.. but, by mistake Svr02 is set to distributor, publisher. (Publisher/distributor are on the same comp..)

I want to fix this..
How?

I think I have to remove replication on both side and Reset from the first.
but, I don't know how to remove replication either..

Please reply with any thougt...Use Replication menu option in EM. You can also check stored procedures that can be used to remove it manually (they are all executed in the background when you do it through GUI), but start with EM first.|||Use Replication menu option in EM. You can also check stored procedures that can be used to remove it manually (they are all executed in the background when you do it through GUI), but start with EM first.
I don't understand about EM..
Could you explain more detail..?|||EM is SQL Enterprise Manager.

-PatP

How to remove and move the Distribution database?

We have 3 servers A, B and C.
There were databases on Server B being replicated in C.
The Distribution database is located in server A.
I have been told that the server A is going away.
Question: How do I move the Distribution database from Server A into one of
the other servers?
Do I need to redo the Replication Setup on Servers B and C?
Thanks,
Suresh Kumar
Disclaimer: I tried posting this message in the Replication group but there
were no replies and hence I trying my luck here.Kumar,
I'm trying to envision here because I don't have experience with that
particular case.
I don't think you need to redo the replication. You only need to make sure
the new distribution server is IDENTICAL to the old one. So how do you
mirror the distribution server?
1. Pause the publisher (B). Make sure all transactions are commited. Stop
replication by stopping all agents (log reader, distribution agents,
snapshot agents, etc.) so that there is no open transactions.
2. Backup master, msdb, distribution db on the distribution server. Script
out logins;
3. Bring down the distriubition server;
4. Turn on the new server. Make sure it is set up exactly the same as the
old distribution server. Rename it to A. check IP address, DNS entries, etc.
5. Install SQL server with same version and service packs. Rename the SQL
server name to what is was called on A.
6. Restore master, msdb and distribution databases; Don't forget to run the
login script to recreate them on the new server.
7. At this point, the new server looks the same as the old one. All
replication related tables are there...Neither the publisher nor subscriber
will notice that the server is no longer what is was;
8. Restart replication agents. You should rock...
Richard
"Suresh Kumar" <skumat@.pcdiDOTcom> wrote in message
news:eaim$%23EWDHA.1204@.TK2MSFTNGP12.phx.gbl...
> We have 3 servers A, B and C.
> There were databases on Server B being replicated in C.
> The Distribution database is located in server A.
> I have been told that the server A is going away.
> Question: How do I move the Distribution database from Server A into one
of
> the other servers?
> Do I need to redo the Replication Setup on Servers B and C?
> Thanks,
> Suresh Kumar
> Disclaimer: I tried posting this message in the Replication group but
there
> were no replies and hence I trying my luck here.
>|||Suresh,
Please reply to the group.
It seems your plan becomes more difficult. If you move distribution db to
either B or C, then both server need to reconfigure 'cause they now have to
repoint to the new distribution server. The system tables involved in
replications are not easy to modify to reflect the change. Although it might
be doable, it takes pain to get everything seamless. Considering the effort
and difficulty, you'd rather script out the replication, sever it, and set
up from scratch. Once you get publisher, distributor, and subscriber in
place, you can change the server name in the script and apply on the
publisher, or even do it manually.
Richard
"Suresh Kumar" <skumat@.pcdiDOTcom> wrote in message
news:eaim$%23EWDHA.1204@.TK2MSFTNGP12.phx.gbl...
> We have 3 servers A, B and C.
> There were databases on Server B being replicated in C.
> The Distribution database is located in server A.
> I have been told that the server A is going away.
> Question: How do I move the Distribution database from Server A into one
of
> the other servers?
> Do I need to redo the Replication Setup on Servers B and C?
> Thanks,
> Suresh Kumar
> Disclaimer: I tried posting this message in the Replication group but
there
> were no replies and hence I trying my luck here.
>|||Richard,
Thanks for your input.
Lucky for me the Replication database has not gone to production yet.
Hence, as per your suggestion, I was able to tear it down and rebuild it
from scratch.
My 2 questions now are:
- There is still an old Distribution database in Server A. How do I delete
it. The Delete is dimmed out under Replication/Distributor properties even
though there are no subscriptions to that database. Can I just delete the
old Ditribution database on Server A (by deleting thru DB properties)
- The Publication and distribution are now on Server B. I am not able to do
pull subscriptions from Server C unless I allow 'Anonymous' subscriptions
for the Publications in B. What are the implications of allowing Anonymous
subsriptions? Does this make us more vulnerable from the securities point of
view?
Thanks,
Suresh Kumar
"Richard Ding" <dingr@.cleanharbors.com> wrote in message
news:%237nfTHHWDHA.652@.tk2msftngp13.phx.gbl...
> Suresh,
> Please reply to the group.
> It seems your plan becomes more difficult. If you move distribution db to
> either B or C, then both server need to reconfigure 'cause they now have
to
> repoint to the new distribution server. The system tables involved in
> replications are not easy to modify to reflect the change. Although it
might
> be doable, it takes pain to get everything seamless. Considering the
effort
> and difficulty, you'd rather script out the replication, sever it, and set
> up from scratch. Once you get publisher, distributor, and subscriber in
> place, you can change the server name in the script and apply on the
> publisher, or even do it manually.
>
> Richard
> "Suresh Kumar" <skumat@.pcdiDOTcom> wrote in message
> news:eaim$%23EWDHA.1204@.TK2MSFTNGP12.phx.gbl...
> > We have 3 servers A, B and C.
> > There were databases on Server B being replicated in C.
> > The Distribution database is located in server A.
> >
> > I have been told that the server A is going away.
> >
> > Question: How do I move the Distribution database from Server A into one
> of
> > the other servers?
> > Do I need to redo the Replication Setup on Servers B and C?
> >
> > Thanks,
> > Suresh Kumar
> >
> > Disclaimer: I tried posting this message in the Replication group but
> there
> > were no replies and hence I trying my luck here.
> >
> >
>|||Hari,
Thanks for your input.
Suresh
<hkvats_1999@.yahoo.com> wrote in message
news:68c8c86d.0308040059.7e3e8d5e@.posting.google.com...
> Hi Suresh,
> You need to follow the complete process for Disabling Distributor.
> --Deletion of Distribution Database
> Execute sp_dropdistributiondb to delete a distribution database.
> --Disable distributors
> Execute sp_dropdistributor with @.no_checks=1
> 'Anonymous' subscriptions
> ==================================================================> Anonymous subscriptions to allow Subscribers unknown to the Publisher
> to subscribe to this publication and not able to change this after the
> publication is created.
> I suggest you go thru with detailed description on this in BOOKS
> ONLINE Topic titled =============="Anonymous Subscriptions"
>
> regards
> Hari Sharma, India

how to reflect schema changes at subscriber using transactional replication

Hi

I need to setup transactional replication for a production server.

The tables (articles) at publisher being replicated can expect schema changes.

Is there any way to reflect schema changes at subscriber using transactional replication.

Early Thanks,

Salman Shehbaz.

If this is SQL Server 2005, the schema changes at publisher can be automatically replicated to subscriber.

If this is SQL Server 2000, you should make schema changes through proc sp_repladdcolumn or sp_repldropcolumn when adding or dropping columns. Other schema changes can not be replicated in SQL Server 2000.

How to Recover committed Transactions from SQL Server Log(.ldf) file?

Hi ,

I got problem in production server at client place(No backup copy & not replicated,it's a SQL SERVER 2000 Enterprise server),by mistake client updated the data without using where condition then updated lakhs of rows (in SQL server autocommited),Now I need to recover this data from LOG file(.ldf).I tried with LOG EXPLORER(Third party tool) Trail version recovered from default database(Northwind,Pubs).But client not willing purchase this S/W for simple cause,How can we recover the data from LOG file.

1.Can we write the Program in C# to read the SQL Server Log and show the past transactions?
2.Is There any Stored procedures exist in SQL Server to read the day transactions in log file and take the backup?
3. How to read Transactions Log file in SQL Server 2000?

It's very Urgent,I am not expert in SQL Server 2000.

Could U Please Help me with possible solutions.

Regards,
Harikrishna.Does the database use the Full recovery model? If so, you can use point-in-time recovery, although it would erase any transactions committed after the mistaken one. If you are using the Simple recovery model, I don't think the data exists in the transaction log, but I am uncertain.

How to query for records that have not been replicated

Hi,

I am using Merge Replication for synchronizing a bunch of laptops
running MSDE with a central SQL Server 2000 production server.

This database is used by an application that needs to know which
records have not yet been replicated, at any givem time.

Here's a simple scenario:

User A in laptop X starts his copy of the application. He syncs his
MSDE database through the application, to match the current central
servers' data. He then proceeds to add new records through the
application and, after he is done, he synchronizes his database with
the central server, through the application.

At any given time, the user might kill the application. He might add
some records today, a few more tomorrow or in a week and should be able
to change and delete records that have not yet been merged into the
production server.

The problem is that SQL Server does not have an easy way to tell which
records in the subscription tables have been inserted but not yet
replicated. I have been using the following query:

SELECT rowguid
FROM [MyTable]
INNER JOIN (
SELECT rowguid AS rep_id
FROM msmerge_contents
WHERE generation = joinchangegen AND generation = (
SELECT MAX(generation)
FROM msmerge_genhistory )
) dtable
ON rowguid_rep = dtable.rep_id

This query works for most cases but fails to identify the first record
created immediatly after a synchronization event.

What I would like to know is if there is a correct way of identifying
records which are "not-yet-replicated" on a given table that is part of
a merge replication process like the one described above.
Thanks in advance.<miltonmoura@.gmail.com> wrote in message
news:1104839914.237873.95740@.f14g2000cwb.googlegro ups.com...
> Hi,
> I am using Merge Replication for synchronizing a bunch of laptops
> running MSDE with a central SQL Server 2000 production server.

<snip
> What I would like to know is if there is a correct way of identifying
> records which are "not-yet-replicated" on a given table that is part of
> a merge replication process like the one described above.
> Thanks in advance.

I have no idea myself, but you might get a better response in
microsoft.public.sqlserver.replication.

Simon