Showing posts with label further. Show all posts
Showing posts with label further. Show all posts

Wednesday, March 28, 2012

RMO ReplicationDatabase Class Can't Program Peer-to-Peer?

Just reading the documentation on RMO programming and noticed that it is silent about peer-to-peer replication. Further, the ReplicationDatabase class has neither a property indicating whether peer-to-peer is enabled, nor a method (or get/set) to enable peer-to-peer. Is peer-to-peer publication outside the scope of RMO programming?

Curious minds want to know...

Thanks.

Randy

You can specify the attributes of the transpublicaiton objec as

PublicationAttributes.AllowInitializationFromBackup | PublicationAttributes.EnabledForPeerToPeer

to create a pulbiction for P2P replication.

Similarily, you can use this attribute to check if the publciation is enalbed for P2P or not.

HTP.

thanks

Yunwen

RMO ReplicationDatabase Class Can't Program Peer-to-Peer?

Just reading the documentation on RMO programming and noticed that it is silent about peer-to-peer replication. Further, the ReplicationDatabase class has neither a property indicating whether peer-to-peer is enabled, nor a method (or get/set) to enable peer-to-peer. Is peer-to-peer publication outside the scope of RMO programming?

Curious minds want to know...

Thanks.

Randy

You can specify the attributes of the transpublicaiton objec as

PublicationAttributes.AllowInitializationFromBackup | PublicationAttributes.EnabledForPeerToPeer

to create a pulbiction for P2P replication.

Similarily, you can use this attribute to check if the publciation is enalbed for P2P or not.

HTP.

thanks

Yunwen

Wednesday, March 21, 2012

RFC: Trigger uodating records in INSERTED Table

1) We have a trigger which applies further changes to the inserted/updated
records. Is this fundamentally bad or an acceptable practice?
2) We suspect that one version of such a trigger is causing deadlocks.
Interestingly this does not seem to happen if we use a cursor. See two
versions below. Any insights why the behavior differs?
Looking forward to your comments,
Jonathan Orgel
-- Suspected of causing dead lock
CREATE TRIGGER IU_DOCUMENTS ON DOCUMENTS
FOR INSERT, UPDATE
AS
BEGIN
UPDATE DOCUMENTS SET X=Y WHERE DOCUMENTID IN (SELECT DOCUMENTID FROM
INSERTED)
END
-- OK...
CREATE TRIGGER IU_DOCUMENTS ON DOCUMENTS
FOR INSERT, UPDATE
AS
BEGIN
DECLARE IndexCursor CURSOR LOCAL STATIC FOR SELECT DOCUMENTID FROM
INSERTED
OPEN IndexCursor
FETCH NEXT FROM IndexCursor INTO @.DOCUMENTID
WHILE @.@.FETCH_STATUS = 0
BEGIN
UPDATE DOCUMENTS SET X=Y WHERE DOCUMENTID = @.DOCUMENTID
FETCH NEXT FROM IndexCursor INTO @.DOCUMENTID
END
CLOSE IndexCursor
DEALLOCATE IndexCursor
ENDRewrite your first trigger to be like the following
CREATE TRIGGER IU_DOCUMENTS ON DOCUMENTS
FOR INSERT, UPDATE
AS
BEGIN
UPDATE
a
SET
X=Y
from
documents a inner join inserted b on
a.documentid=b.documentid
END
I think you are getting deadlocks because of "where documentid in ..."
syntax. Usually this causes SQL Server not to use index optimisation, and
would attempt to do a table scan. Since your code is also doing an update on
the same table, this would cause deadlocks. Also make sure you have an index
on documentid. By the look of things, documentid should be the primary key
and should obviously have been indexed to start with.
HTH
"Jonathan Orgel" <Jonathan@.srssoft.com> wrote in message
news:ek1TflmUGHA.1728@.TK2MSFTNGP11.phx.gbl...
> 1) We have a trigger which applies further changes to the inserted/updated
> records. Is this fundamentally bad or an acceptable practice?
> 2) We suspect that one version of such a trigger is causing deadlocks.
> Interestingly this does not seem to happen if we use a cursor. See two
> versions below. Any insights why the behavior differs?
> Looking forward to your comments,
> Jonathan Orgel
> -- Suspected of causing dead lock
> CREATE TRIGGER IU_DOCUMENTS ON DOCUMENTS
> FOR INSERT, UPDATE
> AS
> BEGIN
> UPDATE DOCUMENTS SET X=Y WHERE DOCUMENTID IN (SELECT DOCUMENTID FROM
> INSERTED)
> END
> -- OK...
> CREATE TRIGGER IU_DOCUMENTS ON DOCUMENTS
> FOR INSERT, UPDATE
> AS
> BEGIN
> DECLARE IndexCursor CURSOR LOCAL STATIC FOR SELECT DOCUMENTID FROM
> INSERTED
> OPEN IndexCursor
> FETCH NEXT FROM IndexCursor INTO @.DOCUMENTID
> WHILE @.@.FETCH_STATUS = 0
> BEGIN
> UPDATE DOCUMENTS SET X=Y WHERE DOCUMENTID = @.DOCUMENTID
> FETCH NEXT FROM IndexCursor INTO @.DOCUMENTID
> END
> CLOSE IndexCursor
> DEALLOCATE IndexCursor
> END
>
>