Re: new bcp tables after 2005 upgrade
- From: Doug <Doug@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 28 May 2008 12:51:04 -0700
Hilary,
We don't do dynamic snapshots, at least not intentionally.
We have @dynamic_filters = N''false''
Here is the how publication is created (some identification info altered).
Doug
Set @sqlstring = 'use [' + @master_machine + '] ' + 'exec
sp_addmergepublication @publication = N''Last'', @description = N''Merge
publication of ' + @master_machine + ' database from Publisher
host-machine.'', @retention = 0, @sync_mode = N''character'', @allow_push =
N''true'', @allow_pull = N''true'', @allow_anonymous = N''true'',
@enabled_for_internet = N''true'', @conflict_logging = N''publisher'',
@dynamic_filters = N''false'', @snapshot_in_defaultfolder = N''false'',
@alt_snapshot_folder = N''\\host-machine\H$\Snapshot'', @compress_snapshot =
N''true'', @ftp_port = 21, @ftp_login = N''xyz'', @ftp_password =
N''xzypwd'', @ftp_address = N''ftp-server'', @conflict_retention = 45,
@keep_partition_changes = N''false'', @allow_subscription_copy = N''false'',
@allow_synctoalternate = N''false'', @add_to_active_directory = N''false'',
@max_concurrent_merge = 0, @max_concurrent_dynamic_snapshots = 0'
EXEC sp_executesql @SQLString
"Hilary Cotter" wrote:
It appears you are doing dynamic snapshots. I think the for all is your.
unfiltered articles.
"Doug" <Doug@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1D49D023-9BC5-41B5-ACEE-FD6DADB34DBB@xxxxxxxxxxxxxxxx
I'll start off by saying these questions were submitted to Microsoft and
no
one can give us an answer without them doing a source code review. Their
response was "these are internal BCP scripts that are used by SQL"....yes,
I
know that....that doesn't help to explain why the system created them. At
this point, I don't want my compary to pay support hours for Microsoft
personnel to learn what their software does.
--------------------
We've had merge publication in place for several years.
Last year, we added some tables/articles to publications.
After the upgrade from SQL Server 2000 SP4 Standard to SQL Server 2005 SP2
Standard, when the snapshot was run, the system created some new files
that
had never existed before. Also, and more importantly, these files were
only
created for the articles added after the initial snapshot was created.
Articles existing in the intial snapshot did not have these type of files
created.
Examples of these files for a SA_MOVE table that was added to an
existing
publication:
MSmerge_contents_SA_MOVE.bcp
MSmerge_contents_SA_MOVE_forall.bcp
MSmerge_rowtrack_SA_MOVE90.bcp
sysmergesubsetfilters_SA_MOVE.bcp
sysmergesubsetfilters_SA_MOVE90.bcp
Also some new bcps created were:
MSmerge_contents90_forall.bcp
MSmerge_genhistory90.bcp
MSmerge_rowtrack90.bcp
sysmergesubsetfilters90.bcp
The system wanted to apply these files before it would start synchronizing
data so they had to be delivered to the subscriber. It appears it was the
sysmergesubsetfilters_ files that it wanted to apply. These are all 0 in
size and we do not have filter on(at least not as far as I know...see
the
addmergearticle code below).
New databases created this year that had all of the articles defined in
the
publication before the initial snapshot was taken did not get these
additional files created, nor did the system want to try to send files to
the
subscriber before syncrhonization could begin.
This is an example of how an article had been cretead under SQL Server
2000
when adding a new database, before an initial snapshot is run:
exec sp_addmergearticle @publication = N'Last', @article = N'SA_MOVE',
@source_owner = N'dbo', @source_object = N'SA_MOVE', @type = N'table',
@description = null, @column_tracking = N'true', @pre_creation_cmd =
N'drop',
@creation_script = null, @schema_option = 0x000000003000EFF1,
@article_resolver = null, @subset_filterclause = null, @vertical_partition
=
N'false', @destination_owner = N'dbo', @verify_resolver_signature = 0,
@allow_interactive_resolver = N'false', @fast_multicol_updateproc =
N'true',
@check_permissions = 0
This is an example of how an article was added under SQL Server 2000 to an
existing publication that already had the initial snapshot run:
exec sp_addmergearticle @publication = N'Last', @article = N'SA_MOVE',
@source_owner = N'dbo', @source_object = N'SA_MOVE', @type = N'table',
@description = null, @column_tracking = N'true', @pre_creation_cmd =
N'drop',
@creation_script = null, @schema_option = 0x000000000000EFF1,
@article_resolver = null, @subset_filterclause = null, @vertical_partition
=
N'false', @destination_owner = N'dbo', @auto_identity_range = N'false',
@verify_resolver_signature = 0, @allow_interactive_resolver = N'false',
@fast_multicol_updateproc = N'true', @check_permissions = 0,
@force_invalidate_snapshot = 1
A few questions:
Does anyone have an idea why the system created these files are part of
the
2005 upgrade?
What is the real purpose of the files with names such as _forall.bcp ?
Thanks for any help/info on this,
Doug
- References:
- new bcp tables after 2005 upgrade
- From: Doug
- Re: new bcp tables after 2005 upgrade
- From: Hilary Cotter
- new bcp tables after 2005 upgrade
- Prev by Date: RE: Merge Replication - SP
- Next by Date: Replication over a slow wan link
- Previous by thread: Re: new bcp tables after 2005 upgrade
- Next by thread: Opinions on this strategy
- Index(es):
Relevant Pages
|
