Showing posts with label replicated. Show all posts
Showing posts with label replicated. Show all posts

Monday, March 19, 2012

New records were not replicated on publisher and subscriber

I have seen this happen in 2 circumstances:
(1) Firstly when the filter was set to 1=2 and inserts
were made while the merge agent was running
(2) If you bulk insert the rows and choose the defaults,
then FIRE_TRIGGERS is false and consequently the rows are
not added to MSmerge_contents.
In either case, you need to run sp_addtabletocontents to
include the rows then resynchronise. Alternatively you
can use sp_mergedummyupdate for a single row.
rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Paul,
Thanks for the answer, I would give it a try.
Hope it will solve my problem.
Thanks again, and more power.
Roland
"Paul Ibison" wrote:

> I have seen this happen in 2 circumstances:
> (1) Firstly when the filter was set to 1=2 and inserts
> were made while the merge agent was running
> (2) If you bulk insert the rows and choose the defaults,
> then FIRE_TRIGGERS is false and consequently the rows are
> not added to MSmerge_contents.
> In either case, you need to run sp_addtabletocontents to
> include the rows then resynchronise. Alternatively you
> can use sp_mergedummyupdate for a single row.
> rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>

Monday, March 12, 2012

New Publication - Snapshot Error

Help!
Some genius cancelled a replication job that was very close to completing the Initial Snapshot of a database being replicated (Transactional) from one server to another.
Is the only thing necessary to do a 'Reinitialize' of this publication?
Is there any way around having the tables locked when the Snapshot is being generated?
(This is why the doofus killed the job)
Any help is greatly appreciated!
You might be able to get away with a concurrent snapshot if you are using transactional replication. On your publication properties, clcik the snapshot tab, and select concurrent access during snapshot generation.
Another Snapshot will be generated but there will be far less locking.
If you can kick all your users off the database you can DTS the data over. This is faster than a snapshot.
To get this to work you should
1) create a new database.
2) script out the tables you are replicating, and any other objects you are replicating, and run this script in the new database.
3) publish this database and objects to a second new database on the same server.
4) script out the objects and the stored procedures and then run this in the subscriber.
This way your objects will be the way replication wants them and you will have the necessary replication stored procedures. Then do your DTS and then do a no-sync subscription.
DTS can be twice as fast as a snapshot generation and distribution.
It is critical that you be able to prevent any updates from happening to your publication database while you do this.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"JLS" wrote:

> Help!
> Some genius cancelled a replication job that was very close to completing the Initial Snapshot of a database being replicated (Transactional) from one server to another.
> Is the only thing necessary to do a 'Reinitialize' of this publication?
> Is there any way around having the tables locked when the Snapshot is being generated?
> (This is why the doofus killed the job)
> Any help is greatly appreciated!
|||Thanx!
Any way to buy a copy of your book before August 15?
"Hilary Cotter" <hilaryk@.att.net> wrote in message
news:ED801206-889D-42F6-A590-663BC63F3BBA@.microsoft.com...
> You might be able to get away with a concurrent snapshot if you are using
transactional replication. On your publication properties, clcik the
snapshot tab, and select concurrent access during snapshot generation.
> Another Snapshot will be generated but there will be far less locking.
> If you can kick all your users off the database you can DTS the data over.
This is faster than a snapshot.
> To get this to work you should
> 1) create a new database.
> 2) script out the tables you are replicating, and any other objects you
are replicating, and run this script in the new database.
> 3) publish this database and objects to a second new database on the same
server.
> 4) script out the objects and the stored procedures and then run this in
the subscriber.
> This way your objects will be the way replication wants them and you will
have the necessary replication stored procedures. Then do your DTS and then
do a no-sync subscription.
> DTS can be twice as fast as a snapshot generation and distribution.
> It is critical that you be able to prevent any updates from happening to
your publication database while you do this.[vbcol=seagreen]
> --
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
>
> "JLS" wrote:
completing the Initial Snapshot of a database being replicated
(Transactional) from one server to another.[vbcol=seagreen]
being generated?[vbcol=seagreen]
|||no. There may be some proofs out in a month.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"JLS" <jlshoop@.hotmail.com> wrote in message
news:%23qw9qmIWEHA.1380@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> Thanx!
> Any way to buy a copy of your book before August 15?
> "Hilary Cotter" <hilaryk@.att.net> wrote in message
> news:ED801206-889D-42F6-A590-663BC63F3BBA@.microsoft.com...
using[vbcol=seagreen]
> transactional replication. On your publication properties, clcik the
> snapshot tab, and select concurrent access during snapshot generation.
over.[vbcol=seagreen]
> This is faster than a snapshot.
> are replicating, and run this script in the new database.
same[vbcol=seagreen]
> server.
> the subscriber.
will
> have the necessary replication stored procedures. Then do your DTS and
then[vbcol=seagreen]
> do a no-sync subscription.
> your publication database while you do this.
> completing the Initial Snapshot of a database being replicated
> (Transactional) from one server to another.
publication?
> being generated?
>