February 27, 2003 at 12:52 pm
Does anyone have an explanation of the structure of this SP? I had to recently add a column and modify the sp and noticed the bitmap being used.
Rob DeMotsis
Sr. SQL Server DBA
Rob DeMotsis
Sr. SQL Server DBA
February 27, 2003 at 1:31 pm
If think that if you add a variable c(number of last column, like 12), before the bitmap variable it ahould work.
Maybe you should let SQL to built it. If you can't change the structure of your replication, create on a test Server, a publication with only the modified table and let sql to build all the sp. Then copy that sp into your production server
February 27, 2003 at 2:12 pm
The original stored proc that was created during the setup process is still intact. I only had to add the new column to the sp. Really I was just trying to figure out the meanings of some of the code behind it.
Rob DeMotsis
Sr. SQL Server DBA
Rob DeMotsis
Sr. SQL Server DBA
March 4, 2003 at 3:38 pm
Official word from MS
"As you probably know this is a system-generated stored procedure. It is
placed in the target DB when a subscription is created and initialized for
replication. The name, parameter list and contents of the stored
procedure are dependent on the table definition, type of action being
performed and type of replication. There will be one stored proc per
action (insert, updated, delete) per replicated table. In this case it
looks like transaction replication.
You can use the keyword IsReplProc with the built-in SQL function
OBJECTPROPERTY to see which SPs are replication related.
You can modify the proc to perform special actions (like to populate
remote applications or to handle large initializations) but we would not
suggest this unless you really know what your doing. It can cause
locking and performance issues if not done right and the stored
procedures get re-written if the subscription is re-initialized.
The stored procedure's parameters correspond to columns in the table (in
order). The bitmap just shows which columns were modified (the idea is
to reduce overhead by modifying only the columns that were truly changed
in the original UPDATE statement)."
Rob DeMotsis
Sr. SQL Server DBA
Rob DeMotsis
Sr. SQL Server DBA
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply