We have a script, that we use to create a publication and its articles, along with a pull subscription. It's pretty basic, as we don't explicitly exclude any articles, rather take them all across to the subscriber (a database used for queries that our reporting uses, to prevent excessive load on the application db).
The script as part of setting up the publication articles loops over each article in the source database and for a tables, executes the following:
DECLARE @Ins nvarchar(255) = 'CALL sp_MSins_'+@articleSchema+@articleName
DECLARE @Del nvarchar(255) = 'CALL sp_MSdel_'+@articleSchema+@articleName
DECLARE @Upd nvarchar(255) = 'CALL sp_MSupd_'+@articleSchema+@articleName
exec sp_addarticle
@publication = @PublishName,
@article = @Joined,
@source_owner = @articleSchema,
@source_object = @articleName,
@type = N'logbased',
@description = null,
@creation_script = null,
@pre_creation_cmd = N'drop',
@schema_option = 0x00000000080350DF,
@identityrangemanagementoption = N'manual',
@destination_table = @articleName,
@destination_owner = @articleSchema,
@vertical_partition = N'false',
@ins_cmd = @Ins,
@del_cmd = @Del,
@upd_cmd =@Upd
My issue is with the @schema_option parameter for the sp_addarticle stored procedure.
I used the script found here:
https://blogs.msdn.microsoft.com/repltalk/2010/02/24/decrypting-schema_option-parameters-binary-value-for-a-transactional-replication-article/
for checking my calculated (bitwise or) value of 0x00000000080350DF and according to that script the following options have been enabled for table articles:
**SCHEMA OPTIONS HERE ARE**
—————————————
0x01 Generates the object creation script (CREATE TABLE, CREATE PROCEDURE, and so on). This value is the default for stored procedure articles.
0x02 – Generates the stored procedures that propagate changes for the article, if defined.
0x04 – Identity columns are scripted using the IDENTITY property.
0x08 – Replicate timestamp columns. If not set, timestamp columns are replicated as binary.
0x10 – Generates a corresponding clustered index. Even if this option is not set, indexes related to primary keys and unique constraints are generated if they are already defined on a published table.
0x40 – Generates corresponding nonclustered indexes. Even if this option is not set, indexes related to primary keys and unique constraints are generated if they are already defined on a published table.
0x80 – Replicates primary key constraints. Any indexes related to the constraint are also replicated, even if options 0x10 and 0x40 are not enabled.
0x1000 – Replicates column-level collation
0x4000 – Replicates UNIQUE constraints. Any indexes related to the constraint are also replicated, even if options 0x10 and 0x40 are not enabled
0x10000 – Replicates CHECK constraints as NOT FOR REPLICATION so that the constraints are not enforced during synchronization
0x20000 – Replicates FOREIGN KEY constraints as NOT FOR REPLICATION so that the constraints are not enforced during synchronization
0x8000000 – Creates any schemas not already present on the subscriber
As you can see, it would appear as though the 0x40 option for enabling the generation of the nonclustered indexes should have been enabled for the table articles.
However, after the snapshot agent is started, a snapshot produced and the log reader agent does its thing, if I access the properties of the publication, I can see that for table articles, the setting for "Copy nonclustered indexes" is set to false.
Does anyone know why this option has not been enabled for the table articles? I have been trying to interpret the documentation on technet: https://technet.microsoft.com/en-us/library/ms173857(v=sql.105).aspx but haven't spotted a reason why this flag would be ignored.
I cannot merely change the option in the properties dialog within management studio, as for our product we don't necessarily have direct access to the sql instance of our clients, but have to execute scripts remotely from an installation machine via powershell, of which this script is one.
Thanks in advance.