Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
pontifikas
Starting Member
32 Posts |
 Posted - 2004-09-09 : 04:47:55
|
I know there are many threads on this issue but they dont have enlightening enough answers(in fact they have too few) and since my need is quite simple I decided to open a new thread.I have triggers on the tables of my database that fire whenever a change occures, filling a LOG table with the corresponding action(Insertion,Update etc).I have replicated the database(Transactional with updating subscribers)but the trigger were not replicated.Is there a way to replicate them also?It whould be a burden to create them all again.I know that the changes on the Publisher's LOG table are also replicated but it is a matter of security for my application to be able to work normaly both on the publisher and the subscriber(in case the publisher goes down).Thanks in advance |
|
|
jen
Master Smack Fu Yak Hacker
4110 Posts |
Posted - 2004-09-09 : 05:48:49
|
| you're aware that any changes made on the publisher will be reflected on the subscriber? and if you change anything on the subscriber that can cause identical ID's will cause replication failure? Also, you'll have a different column computation (if you're using one) since you'll have one additional column on the subscriber's tables.but yes you can include triggers, it's under the publication properties, click articles, click the button next to the name of the table and check user triggers under snapshot. you need to reinitialize the subscriptions so that the snapshot will be generated again and apply to the subscribers. |
 |
|
|
pontifikas
Starting Member
32 Posts |
Posted - 2004-09-09 : 06:16:38
|
| I didnt quite got this.You mean that, the change made on the subscriber fires a trigger thus modifing the LOG table of the subscriber, and then also comes the change from the LOG file of the publisher and I End Up with double input? |
|
|
|
jen
Master Smack Fu Yak Hacker
4110 Posts |
Posted - 2004-09-09 : 07:14:16
|
what i meant is that if you use replication, whatever changes you have on publisher will be reflected on subscriber. if you have a trigger that does the same, then you'll have a double input. Also, you'll get an additional column which the replication uses for identifying which row was modified. just be careful on what your trigger will do on the subscriber side, our subscribers are usually for reports or read only and i've explicitly denied users from making any changes except for the account used in replication. there were so many encounters wherein users "accidentally" added or deleted data into subscriber and we end up with failed replication (this is based on the parameter that you're replication is transactional and not merge).quote:
Originally posted by pontifikas
I didnt quite got this.You mean that, the change made on the subscriber fires a trigger thus modifing the LOG table of the subscriber, and then also comes the change from the LOG file of the publisher and I End Up with double input?
|
|
|
|
pontifikas
Starting Member
32 Posts |
Posted - 2004-09-09 : 08:12:59
|
| In my case the solution might be to exclude the LOG table from the replication articles.I'll check it and monitor it's behaviour.Thanks a lot mate :) |
|
|
|
|
|
|
|
|
Replicating Triggers