Hi
I'm Running SQL 2k - Mainly Merge Replication.
Can Someone point me in the right direction on how best to Alert myself/Operator via email when a conflict occurs.
I use xp_sendmail regularly so can deal with that part
I've tried looking for a solution but with no success.
Having to keep opening the Conflict Viewer to check is becomming a Bit Tiresome.
The Only way I can think of is running a batch Job to look at the rowcount of conflict tables (Possibly using a cursor and dynamically built Select Count(*) statements from sysobjects to get conflict table names).
or
If Conflicts are flagged in the system Replication tables query them but I don't know which table if any exist.
Theres gotta be an easier way - I must be missing something
Any Help Greatly appreciated
thx
GWCheck Lumigent (http://www.lumigent.com) website for latest tool on notification and its free.|||Cool
thx again Satya
GW
Showing posts with label auto. Show all posts
Showing posts with label auto. Show all posts
Friday, March 23, 2012
Tuesday, March 20, 2012
Replication and uniqueidentifier
Hope someone can help with this.
I have one database where all the tables were joined by a auto incrementing
column.
Now we are trying to see if we can move to having multiple databases
(replication) across different offices which has the same tables. Each office
would merge in their records but can see other offices records as well and
possibly make updates to it. We would try to implement two way merging.
We are coming to the realization that we can't use the autoincrementing id
and now possibly join all the tables using a unique identifier. We can't use
the auto id since we have multiple sql servers now and conflict could occur.
Two questions:
1. Is joining by unique identifier good
2. Can we implement merge replication using this unique identifier as I read
that sql server adds its own unique identifier column.
Any help would be appreciated.
Abdul Rauf
In general avoid guids when possible. Check out this link for a discussion
of the reasons why.
http://www.aspfaq.com/show.asp?id=2504
Basically to avoid primary key collisions you need to ensure that the data
which is entered in one database will never have the same primary key value
as data which is entered in another database.
What you really need to do is partitioning. You can use different identity
seeds to achieve this please check out
mk:@.MSITStore:C:\Program%20Files\Microsoft%20SQL%2 0Server\80
HTH
"Abdul Rauf" <AbdulRauf@.discussions.microsoft.com> wrote in message
news:3F3DAC60-B9DE-446C-BF8C-12CF139A106B@.microsoft.com...
> Hope someone can help with this.
> I have one database where all the tables were joined by a auto
incrementing
> column.
> Now we are trying to see if we can move to having multiple databases
> (replication) across different offices which has the same tables. Each
office
> would merge in their records but can see other offices records as well and
> possibly make updates to it. We would try to implement two way merging.
> We are coming to the realization that we can't use the autoincrementing id
> and now possibly join all the tables using a unique identifier. We can't
use
> the auto id since we have multiple sql servers now and conflict could
occur.
> Two questions:
> 1. Is joining by unique identifier good
> 2. Can we implement merge replication using this unique identifier as I
read
> that sql server adds its own unique identifier column.
> Any help would be appreciated.
> Abdul Rauf
I have one database where all the tables were joined by a auto incrementing
column.
Now we are trying to see if we can move to having multiple databases
(replication) across different offices which has the same tables. Each office
would merge in their records but can see other offices records as well and
possibly make updates to it. We would try to implement two way merging.
We are coming to the realization that we can't use the autoincrementing id
and now possibly join all the tables using a unique identifier. We can't use
the auto id since we have multiple sql servers now and conflict could occur.
Two questions:
1. Is joining by unique identifier good
2. Can we implement merge replication using this unique identifier as I read
that sql server adds its own unique identifier column.
Any help would be appreciated.
Abdul Rauf
In general avoid guids when possible. Check out this link for a discussion
of the reasons why.
http://www.aspfaq.com/show.asp?id=2504
Basically to avoid primary key collisions you need to ensure that the data
which is entered in one database will never have the same primary key value
as data which is entered in another database.
What you really need to do is partitioning. You can use different identity
seeds to achieve this please check out
mk:@.MSITStore:C:\Program%20Files\Microsoft%20SQL%2 0Server\80
HTH
"Abdul Rauf" <AbdulRauf@.discussions.microsoft.com> wrote in message
news:3F3DAC60-B9DE-446C-BF8C-12CF139A106B@.microsoft.com...
> Hope someone can help with this.
> I have one database where all the tables were joined by a auto
incrementing
> column.
> Now we are trying to see if we can move to having multiple databases
> (replication) across different offices which has the same tables. Each
office
> would merge in their records but can see other offices records as well and
> possibly make updates to it. We would try to implement two way merging.
> We are coming to the realization that we can't use the autoincrementing id
> and now possibly join all the tables using a unique identifier. We can't
use
> the auto id since we have multiple sql servers now and conflict could
occur.
> Two questions:
> 1. Is joining by unique identifier good
> 2. Can we implement merge replication using this unique identifier as I
read
> that sql server adds its own unique identifier column.
> Any help would be appreciated.
> Abdul Rauf
Subscribe to:
Posts (Atom)