dbTalk Databases Forums  

Publication w/o logreader agent. Is it possible?

microsoft.public.sqlserver.replication microsoft.public.sqlserver.replication


Discuss Publication w/o logreader agent. Is it possible? in the microsoft.public.sqlserver.replication forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Oskar
 
Posts: n/a

Default Publication w/o logreader agent. Is it possible? - 02-09-2006 , 04:56 AM






Hi,
Is it possible to create a publication without creating a logreader agent at
the same time? I'm on MS SQL Server 2000 SP3a.

-- Many thanks, Oskar


Reply With Quote
  #2  
Old   
Paul Ibison
 
Posts: n/a

Default Re: Publication w/o logreader agent. Is it possible? - 02-09-2006 , 05:34 AM






Oskar - if you are talking about transactional replication, this is an
integral part of the functioning. I'm interested in why would you like to
avoid the logreader agent?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)



Reply With Quote
  #3  
Old   
Oskar
 
Posts: n/a

Default Re: Publication w/o logreader agent. Is it possible? - 02-09-2006 , 07:47 AM



Yes, transactional is what I am talking about. I am interested in this
because I want to have development databases published but I do not want to
have any real replication going on there. This is needed because we must have
identical "change management" in development and production environments.
Looks like I have partly solved this problem by making each development
server a publisher and a distributor, and regenerating the publication from a
script. I even could do without the snapshot agent, but getting rid of the
logreader seems to be tricky, if not impossible.

-- Thanks, Oskar

"Paul Ibison" wrote:

Quote:
Oskar - if you are talking about transactional replication, this is an
integral part of the functioning. I'm interested in why would you like to
avoid the logreader agent?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)




Reply With Quote
  #4  
Old   
Paul Ibison
 
Posts: n/a

Default Re: Publication w/o logreader agent. Is it possible? - 02-09-2006 , 08:19 AM



Oskar,
don't know if this helps, but until the snapshot has run, the log reader
isn't moving any commands to the distribution database. To prevent it
parsing the transaction log you could simply stop it.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)





Reply With Quote
  #5  
Old   
Oskar
 
Posts: n/a

Default Re: Publication w/o logreader agent. Is it possible? - 02-09-2006 , 10:45 AM



That's exactly what I did. I just don't like to stop it manually everytime
the development database gets refreshed - its job name and id changes at
every such refreshing.

-- Oskar

"Paul Ibison" wrote:

Quote:
Oskar,
don't know if this helps, but until the snapshot has run, the log reader
isn't moving any commands to the distribution database. To prevent it
parsing the transaction log you could simply stop it.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)






Reply With Quote
  #6  
Old   
Paul Ibison
 
Posts: n/a

Default Re: Publication w/o logreader agent. Is it possible? - 02-09-2006 , 11:38 AM



I'd add a piece of code at the end of the script which stops and disables
the job - that way you don't need to worry about it afterwards.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)







Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.