Impact of Existing replication

Scenario.
A db published for transactional replication will be backed up and restored
on a server in a different facility. There, all new replication will be
defined (completely different articles, completely different targets)
Question.
Will pre-existing replication prevent correct functioning of the db at the
time of restore and new replication being defined? Dropping replication
prior to backing up the db is not an option.
Thank you for your help
Oscar
Once restored, execute sp_removedbreplication @.dbname = 'MyPubDB', then
reconfigure replication...
ChrisB
MCDBA OCP
www.MyDatabaseAdmin.com
"Oscar" wrote:

> Scenario.
> A db published for transactional replication will be backed up and restored
> on a server in a different facility. There, all new replication will be
> defined (completely different articles, completely different targets)
> Question.
> Will pre-existing replication prevent correct functioning of the db at the
> time of restore and new replication being defined? Dropping replication
> prior to backing up the db is not an option.
> Thank you for your help
> Oscar
>
|||Actually you want to execute:
-- REMOVE TRANSACTION IN LOG TO ALLOW FOR TRUNCATE -
EXEC sp_repldone @.xactid = NULL, @.xact_segno = NULL, @.numtrans = 0, @.time =
0, @.reset = 1
ChrisB
MCDBA OCP
www.MyDatabaseAdmin.com
"Chris" wrote:
[vbcol=seagreen]
> Once restored, execute sp_removedbreplication @.dbname = 'MyPubDB', then
> reconfigure replication...
> ChrisB
> MCDBA OCP
> www.MyDatabaseAdmin.com
> "Oscar" wrote:

immediate updating isnt working

Im doing some testing on Immediate Updating Transactional Replication. I
generated a script to drop the Subscription and Article to a particular
table to add an Identity column on it. After that, I re-added the table to
the Publication and re-snapshotted the table. No problem and all is good at
this point. However now when I insert a record into the Subscriber, the row
isn't getting back to the Publisher *for this table only.* It is working for
other tables though. I scripted out the sp_addarticle for both this table
and a table that the immediate updating is working properly on and they are
identicle with the exception of the names. Whats the dealio? All ideas are
appreciated.
SQL2K SP3
TIA, ChrisR
I figured out whats up. The triggers for Insert, Update, and Deletes arent
being created like they were during the original snapshot. Does anyone know
why?
"ChrisR" <bla@.noemail.com> wrote in message
news:u58jVxkLFHA.2796@.tk2msftngp13.phx.gbl...
> Im doing some testing on Immediate Updating Transactional Replication. I
> generated a script to drop the Subscription and Article to a particular
> table to add an Identity column on it. After that, I re-added the table to
> the Publication and re-snapshotted the table. No problem and all is good
at
> this point. However now when I insert a record into the Subscriber, the
row
> isn't getting back to the Publisher *for this table only.* It is working
for
> other tables though. I scripted out the sp_addarticle for both this table
> and a table that the immediate updating is working properly on and they
are
> identicle with the exception of the names. Whats the dealio? All ideas are
> appreciated.
> --
> SQL2K SP3
> TIA, ChrisR
>
|||how did you resync after making changes to your subscription.
I think it would be best to recreate your snapshot - it sounds like your
metadata is out of sync.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"ChrisR" <bla@.noemail.com> wrote in message
news:%23fFESGmLFHA.1476@.TK2MSFTNGP09.phx.gbl...
> I figured out whats up. The triggers for Insert, Update, and Deletes arent
> being created like they were during the original snapshot. Does anyone
know[vbcol=seagreen]
> why?
>
> "ChrisR" <bla@.noemail.com> wrote in message
> news:u58jVxkLFHA.2796@.tk2msftngp13.phx.gbl...
to[vbcol=seagreen]
> at
> row
> for
table[vbcol=seagreen]
> are
are
>
|||I re-snapshotted the table.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:uKk9rboLFHA.580@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> how did you resync after making changes to your subscription.
> I think it would be best to recreate your snapshot - it sounds like your
> metadata is out of sync.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "ChrisR" <bla@.noemail.com> wrote in message
> news:%23fFESGmLFHA.1476@.TK2MSFTNGP09.phx.gbl...
arent[vbcol=seagreen]
> know
I[vbcol=seagreen]
particular[vbcol=seagreen]
table[vbcol=seagreen]
> to
good[vbcol=seagreen]
the[vbcol=seagreen]
working[vbcol=seagreen]
> table
they
> are
>
|||I realize that - but I think you need to re-snapshot the entire publication.
I had problems like this with merge replication, which could only be solved
by a complete resnapshotting and re-synchronization.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"ChrisR" <bla@.noemail.com> wrote in message
news:eV5KqXvLFHA.3512@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> I re-snapshotted the table.
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:uKk9rboLFHA.580@.TK2MSFTNGP15.phx.gbl...
> arent
Replication.[vbcol=seagreen]
> I
> particular
> table
> good
> the
> working
> they
ideas
>
|||I was afraid of that. Just wanted to make sure we were on the same page.
Thanks Hillary.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:#BL4sBwLFHA.2796@.tk2msftngp13.phx.gbl...
> I realize that - but I think you need to re-snapshot the entire
publication.
> I had problems like this with merge replication, which could only be
solved[vbcol=seagreen]
> by a complete resnapshotting and re-synchronization.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "ChrisR" <bla@.noemail.com> wrote in message
> news:eV5KqXvLFHA.3512@.TK2MSFTNGP15.phx.gbl...
your[vbcol=seagreen]
anyone[vbcol=seagreen]
> Replication.
is[vbcol=seagreen]
Subscriber,[vbcol=seagreen]
this
> ideas
>
sql

Ignoring Source Field

Hi,

I am implementing a Transactional Replication btwn two SQL 2000 servers, which is using Data Transform services (DTS package) to manipulate the data. I need to ignore a source column from replication but that column field value needs to be appended with other field column.

For ex. Let two source fields be named FirstName and LastName. In the target database i need to merge those field values into a Single field called CustomerName. Also i don't want the two source fields to be replicated in the target.

I tried to ignore the field by unchecking the Column Transformation and Mapping screen, but then unable to append the field value to the other field.

Is there any other way to do the above?

Thanks in advance.

urs,
T. Jayakumar

I don't think there is a way to use a field in a transformation but not include it in the package data.

Phil Garding