check replication conflicts programmatically

Hi,
I would like to know if we can check merge replication conflicts
programmatically.
which tables do we need to check for replication conflicts?
By default some conflict_* tables are created. will these contain the
info?
Rgds,
amit
mitsql,
yes the conflict_ tables contain the necessary information. In detail
they contain the column values of the losing replication partner plus
the reason for the conflict and the guid. If you want to be notified
when a conflict occurs you can create an insert trigger on the conflict
tables which either sends a mail or runs some sript/store procedure.
Markus
sql

check replication conflicts programmatically

Hi,
I would like to know if we can check merge replication conflicts
programmatically.
which tables do we need to check for replication conflicts?
By default some conflict_* tables are created. will these contain the
info?
Rgds,
amitmitsql,
yes the conflict_ tables contain the necessary information. In detail
they contain the column values of the losing replication partner plus
the reason for the conflict and the guid. If you want to be notified
when a conflict occurs you can create an insert trigger on the conflict
tables which either sends a mail or runs some sript/store procedure.
Markus

check replication conflicts programmatically

Hi,
I would like to know if we can check merge replication conflicts
programmatically.
which tables do we need to check for replication conflicts?
By default some conflict_* tables are created. will these contain the
info?
Rgds,
amitmitsql,
yes the conflict_ tables contain the necessary information. In detail
they contain the column values of the losing replication partner plus
the reason for the conflict and the guid. If you want to be notified
when a conflict occurs you can create an insert trigger on the conflict
tables which either sends a mail or runs some sript/store procedure.
Markus

check merge replication conflicts

Hi,
I would like to know if we can check merge replication conflicts
programmatically.
which tables do we need to check for replication conflicts?
By default some conflict_* tables are created. will these contain the
info?
Rgds,
amit
Yes - these custom-named tables and MSmerge_delete_conflicts will contain
the info you require.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||thanks a lot.

Chaning password

I have several merge replications running pushing subscriptions from one
server to the other. After some problems we recreated the databases (se
previous questions). However after pushing up all data everything worked fine
until we changed the administrator password on the subsciber server. Now I
get an error message 20084 at the publisher /18452 at the subscriber and the
message "Login failed for user '(null)'. Reason: Not associated with a
trusted SQL Server connection." What is the problem? i have registred the
servers via the 'sa' user and connect via the 'sa' user and have both
sql-server and windows as login possibilities. Sql-server and agent is
started via the administrator account (win2000) but i have stopped and
restarted the service changing the password in the services.
Best wishes
Mats
The "Login failed for user '(null)'. Reason: Not associated with a trusted
SQL Server connection." error normally means one of three things.
The NT account you are using to authenticate with does not have rights to
access the machine, its password is invalid, or you are using windows
authentication only and trying to connect using a SQL account and password.
You have to be a little careful with the account on the subscriber.
When the subscriber's SQL Server agent connects to the publisher it by
default will impersonate the SQL Server agent account on the publisher. In
other words the accounts and passwords of the account the SQL Server agent
on the Subscriber will have to match the account on the Publisher, or will
have to be in the administrator group on the publisher.
You can also specify a SQL account. In this case your SQL Server agent
account on the subscriber will have to match the SQL Server agent account on
the publisher, or be in the administrator group, or have rights to access
the snapshot folder share on the publisher.
I think your best approach, if you can do it, is to make the administrator
accounts on both servers have the same password, or to use another
administrator account on the subscriber, and add this account to the admin
group on the publisher.
HTH - its a little tricky to implement.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"Mats" <Mats@.discussions.microsoft.com> wrote in message
news:E2956017-73FA-4EBA-8D86-F58A0B4D24C7@.microsoft.com...
>I have several merge replications running pushing subscriptions from one
> server to the other. After some problems we recreated the databases (se
> previous questions). However after pushing up all data everything worked
> fine
> until we changed the administrator password on the subsciber server. Now I
> get an error message 20084 at the publisher /18452 at the subscriber and
> the
> message "Login failed for user '(null)'. Reason: Not associated with a
> trusted SQL Server connection." What is the problem? i have registred the
> servers via the 'sa' user and connect via the 'sa' user and have both
> sql-server and windows as login possibilities. Sql-server and agent is
> started via the administrator account (win2000) but i have stopped and
> restarted the service changing the password in the services.
>
> --
> Best wishes
> Mats