i have transactional repl setup with an updatable subscriber. when my
initial snapshot is synced to the subscriber, the tables are dropped fine
but recreated under a non-dbo user (in my case one that is setup named
'dev'). what controls how the publisher/distributor drops/creates the tables
at the subscriber end? this must be where the 'dev' owner is coming from.
thanks.
Terry,
in terms of TSQL this is the @.destination_owner value from sp_addarticle. I
don't have the GUI in front of me right now, but take a look at the article
properties option and there should be an entry to specify this in the list
of properties there.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
Showing posts with label subscriber. Show all posts
Showing posts with label subscriber. Show all posts
Friday, March 9, 2012
Saturday, February 25, 2012
overwrite a record on the subscriber
Hello. I have a table which I replicate to server B. Does it pose any
problems if I update the table Server B, then replication overlays the rows
a minute later? Someone told me that replicated tables keep track of the
last date/time the row was updated, but I thought that was only the
published table. Is this true?
Thank you,
Steve
You are free to update tables on the subscriber if the are part of a
transactional or snapshot publication.
With merge replication the change will make their way back to the publisher.
If you insert records with transactional replication on the subscriber you
may get a primary key violation. If you are ok with this, you can change
your profile of your distribution agent to continue on data consistency
errors. To do this expand Replication monitor in EM, expand the Replication
Agents folder, expand distribution agents folder, right click on your
distribution agent, and select agent profiles. Then select the continue on
data consistency errors profile. Stop and start your distribution agent.
Keep in mind you have lost database consistency between your publisher and
subscriber.
For most replication solutions this is NOT a good thing, but your particular
solution might benefit from it.
"SteveS" <ssinger@.trendmls.com> wrote in message
news:%23uznj2cFEHA.3080@.tk2msftngp13.phx.gbl...
> Hello. I have a table which I replicate to server B. Does it pose any
> problems if I update the table Server B, then replication overlays the
rows
> a minute later? Someone told me that replicated tables keep track of the
> last date/time the row was updated, but I thought that was only the
> published table. Is this true?
> Thank you,
> Steve
>
problems if I update the table Server B, then replication overlays the rows
a minute later? Someone told me that replicated tables keep track of the
last date/time the row was updated, but I thought that was only the
published table. Is this true?
Thank you,
Steve
You are free to update tables on the subscriber if the are part of a
transactional or snapshot publication.
With merge replication the change will make their way back to the publisher.
If you insert records with transactional replication on the subscriber you
may get a primary key violation. If you are ok with this, you can change
your profile of your distribution agent to continue on data consistency
errors. To do this expand Replication monitor in EM, expand the Replication
Agents folder, expand distribution agents folder, right click on your
distribution agent, and select agent profiles. Then select the continue on
data consistency errors profile. Stop and start your distribution agent.
Keep in mind you have lost database consistency between your publisher and
subscriber.
For most replication solutions this is NOT a good thing, but your particular
solution might benefit from it.
"SteveS" <ssinger@.trendmls.com> wrote in message
news:%23uznj2cFEHA.3080@.tk2msftngp13.phx.gbl...
> Hello. I have a table which I replicate to server B. Does it pose any
> problems if I update the table Server B, then replication overlays the
rows
> a minute later? Someone told me that replicated tables keep track of the
> last date/time the row was updated, but I thought that was only the
> published table. Is this true?
> Thank you,
> Steve
>
Subscribe to:
Posts (Atom)