Comment faire pour implémenter bidirectionnelle réplication transactionnelle

Cet article étape par étape explique comment implémenter la réplication transactionnelle bidirectionnelle. Cet article décrit également les problèmes impliqués dans l'implémentation de réplication transactionnelle bidirectionnelle.

Réplication transactionnelle bidirectionnel

Réplication transactionnelle bidirectionnel, également connu sous le nom bidirectionnelle réplication transactionnelle, permet à un serveur à un éditeur et un abonné aux mêmes données. Étant donné que les serveurs qui participer à la réplication sont réplique les modifications aux autres serveurs, les modifications sont ne pas être propagées revenir au serveur d'origine.

Par exemple, si vous disposez de deux serveurs (serveur A et B de serveur), les serveurs sont appelés dans la réplication transactionnelle bidirectionnelle si les deux conditions suivantes sont remplies :

• Les modifications apportées à la table t1 au serveur A sont répliquées à table t1 au serveur b.
• Les modifications apportées à la table t1 au serveur B sont répliquées à table t1 au serveur a.

Par conséquent, si une modification provient d'un serveur, la modification est répliquée sur le serveur B, mais serveur B ne propage pas la même modification au serveur a réplication utilise un mécanisme de détection de bouclage qui le distributeur utilise pour déterminer si pour envoyer les modifications au serveur de départ.

Planification la topologie de réplication transactionnelle bidirectionnelle

Pour la réplication transactionnelle bidirectionnelle, un des serveurs peut agir comme abonné central et tous les autres serveurs s'abonner à l'abonné central. Par conséquent, les modifications qui proviennent sur un serveur sont répliquées sur l'abonné central, et ensuite l'abonné central, réplique à son tour, les modifications vers tous les autres serveurs qui participent à la réplication. Toutefois, à l'aide du mécanisme de détection bouclage, le distributeur cesse le changement d'être propagées au serveur d'origine.

Par exemple, si trois serveurs (serveur A, serveur B et serveur C) participer réplication transactionnelle bidirectionnelle et serveur A est l'abonné central, les éditeurs et le abonnés sont conservées de l'une des manières suivantes :

• Serveur A publie vers le serveur B et c. Server
• Serveur A s'abonne de serveur B et c. Server
• Serveur B publie vers et s'abonne d'uniquement Server a.
• Le serveur C publie vers et s'abonne de Server uniquement a.

Par conséquent, toute modification qui provient au serveur B est répliquée sur serveur A et c. Server

Entre en conflit de bidirectionnelle réplication transactionnelle

Lorsque vous apportez des modifications sur un serveur qui participe dans la réplication, les modifications sont répliquées sur tous les autres serveurs participants. Au cours de cette réplication conflits peuvent se produire et réplication peut échouer. La liste suivante décrit les conflits possibles et les méthodes que vous pouvez éviter ces conflits :

• Si vous insérer un enregistrement qui a une clé dans une table sur un des serveurs et un autre enregistrement a déjà la même clé existe sur les autres serveurs qui participent à la réplication, la réplication ne propage pas les modifications apportées aux autres serveurs.
  
  Action proposée Pour éviter ce problème, assurez-vous que vous utilisez des touches différentes sur chaque serveur qui participe à la réplication. Pour ce faire, affecter une tranche prédéterminée de touches pour chaque serveur qui participe à la réplication. Vous pouvez également utiliser une clé composite sur chaque serveur.
• Lorsque vous mettez à jour un enregistrement qui a été supprimé sur un autre serveur, l'instruction UPDATE affecte zéro lignes sur le serveur où l'enregistrement a été supprimé et la réplication échoue avec une erreur.
  
  suggéré d'action Pour éviter ce problème, effectuez l'une des opérations suivantes :
  • Supprimer le @@ROWCOUNT vérifier après l'instruction UPDATE réelle dans la procédure stockée personnalisée mise à jour.
    
    -ou-
  • Utilisez la -Skiperrors paramètre pour l'agent de distribution ignorer cette erreur. Pour plus savoir ignorant erreurs de réplication transactionnelle, reportez-vous au adresse site Web de Microsoft à l'adresse suivante :
    
    http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx)
    -ou-
  • Recherchez un enregistrement avant de l'instruction UPDATE dans la mise à jour d'une procédure stockée. Si aucun enregistrement n'existe, ignorer l'instruction UPDATE et l'enregistrement est supprimé de tous les abonnés.
• Lorsque vous mettez à jour une colonne dans un enregistrement qui est mis à jour en même temps sur un autre serveur, les données peuvent être différents sur les deux serveurs.
  
  suggéré d'action Pour éviter ce problème, déterminer si les données sont en cours mises à jour en même temps sur d'autres serveurs et alors prendre toute action nécessaire. Pour cela, modifier la procédure stockée mise à jour personnalisées et utiliser XCALL syntaxe pour appeler la mise à jour de procédure stockée. La syntaxe XCALL fournit les valeurs pour toutes les colonnes avant la procédure de mise à jour est appelée et fournit les valeurs mises à jour dans la colonne. Vous pouvez comparer la valeur actuelle de la colonne par rapport à la valeur avant que la procédure de mise à jour stockée est appelée. Si vous voyez des valeurs différentes, la colonne est mises à jour en même temps par des serveurs différents. Vous pouvez personnaliser la procédure stockée pour sélectionner la valeur persiste. Pour plus savoir comment utiliser XCALL, reportez-vous au adresse site Web de Microsoft à l'adresse suivante :
  
  http://msdn2.microsoft.com/en-us/library/Aa237133(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/Aa237133(SQL.80).aspx)
  note Vous pouvez spécifier la syntaxe XCALL à appeler la mise à jour correspondante d'une procédure stockée ou supprimer une procédure stockée à l'aide sp_addarticle au cours de composition. Vous pouvez également spécifier la syntaxe XCALL à l'aide de SQL Server Enterprise Manager. Pour ce faire, procédez comme suit :
  1. Dans SQL Server Enterprise Manager, recherchez la composition que vous souhaitez.
  2. Cliquez avec le bouton droit sur la composition, puis cliquez sur Propriétés .
  3. Cliquez sur l'onglet articles , recherchez l'article et puis cliquez sur le bouton Propriétés article (...) côté à l'article.
  4. Dans la boîte de dialogue Propriétés du tableau article , cliquez sur l'onglet commandes .
  5. Dans la zone de texte remplacer la mise à jour des commandes avec cet appel de procédure stockée , tapez XCALL et puis cliquez sur OK .
  6. Dans la boîte de dialogue Propriétés de publication , cliquez sur OK .
• Lorsque vous mettez à jour des colonnes différentes dans un enregistrement, mises à jour simultanées de différentes colonnes d'un enregistrement peuvent parfois entraîner conflits.
  
  suggéré d'action Pour éviter ce problème, déterminer si les différentes colonnes dans le même enregistrement sont mis à jour en même temps et alors prendre toute action nécessaire. Pour cela, modifiez la procédure stockée mise à jour personnalisées et utilisez ensuite la XCALL syntaxe pour appeler la mise à jour de procédure stockée. Étant donné que la syntaxe XCALL fournit les valeurs avant que la procédure de mise à jour stockée est appelée, vous pouvez ajouter une des options suivantes à la procédure de mise à jour stockée avant l'exécution de la mise à jour actuel :
  • Comparez les valeurs en cours de toutes les colonnes par rapport aux leurs valeurs avant la mise à jour d'une procédure stockée est appelée.
  • Ajouter une colonne pour représenter la version de ligne et pour comparer sa valeur avec sa valeur actuelle avant la mise à jour d'une procédure stockée est appelée.
  Différentes valeurs indiquent que des colonnes différentes sont mis à jour en même temps. Vous pouvez ensuite décider mettre à jour de la colonne.
• Lorsque vous supprimez une ligne qui est mises à jour par un autre serveur en même temps, la réplication peut échouer.
  
  suggéré d'action Pour déterminer si une ligne est mise à jour et supprimée en même temps, utilisez la syntaxe XCALL dans la procédure stockée supprimer. Comparez chaque colonne de la ligne qui est supprimée par rapport aux valeurs avant que la procédure stockée supprimer est appelée. Différentes valeurs indiquent que ces mises à jour et exécutés en même temps. Vous pouvez supprimer ou conserver la ligne mise à jour.
  
  note Même si vous ne supprimez pas l'enregistrement de l'abonné, l'enregistrement n'existe plus sur le serveur qui provient de la suppression instruction.
• Lorsque vous supprimez une ligne qui est supprimée en même temps sur un autre serveur qui participe dans la réplication, la réplication échoue parce que l'instruction DELETE n'affecte pas les lignes de certaines les abonnés.
  
  Action proposée Pour éviter ce problème, effectuez l'une des opérations suivantes :
  • Supprimer le @@ROWCOUNT vérifier après l'instruction DELETE réelle dans la procédure stockée personnalisée mise à jour.
    
    -ou-
  • Utilisez la -Skiperrors paramètre à l'agent de distribution pour ignorer cette erreur. Pour plus savoir ignorant erreurs de réplication transactionnelle, reportez-vous au adresse site Web de Microsoft à l'adresse suivante :
    
    http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx)

note Chaque déploiement peut nécessiter une approche différente pour résoudre ces conflits, selon les besoins. Ces conflits sont plus faciles à résoudre lorsque seuls deux serveurs sont impliqués. Lorsque plus de deux serveurs sont impliquées, vous pourrez utiliser les procédures stockées pour déterminer quel serveur d'origine les modifications. La procédure de mise à jour stockée qui sert à mettre à jour les enregistrements dans le serveur C ne sait pas si le changement provient dans Server A ou b. Server Contrairement à la réplication de fusion, réplication transactionnelle n'est pas conçue pour résoudre les conflits. Déployer la réplication transactionnelle uniquement dans les scénarios où les conflits peuvent être évitées au lieu de résoudre.

Implémenter bidirectionnelle réplication transactionnelle

Pour implémenter la réplication transactionnelle bidirectionnelle, toutes les conditions suivantes doivent être remplies :

• Les données sont synchronisées entre les serveurs chargés de la réplication.
• Procédures stockées qui sont utilisés par la réplication se trouvent dans toutes les bases de données participant à.
• L'abonnement a été configurez à l'aide la @loopback_detection = 'true' paramètre.
  
  note L'option définir @loopback_detection = 'true' n'est pas actuellement disponible dans l'interface utilisateur. Par conséquent, vous devez vous inscrire en utilisant la procédure sp_addsubscription stockées.

Si vous effectuez une sauvegarde et une restauration, souvenez-vous que des sites différents nécessitent différentes contraintes sur la clé primaire pour vous assurer que les clés primaires en double ne sont pas créés. Pensez également à créer tous les contraintes avec la clause non de réplication.

Vous pouvez utiliser l'exemple suivant montre comment configurer la réplication transactionnelle bidirectionnelle sur un ordinateur exécutant SQL Server 2000.

note Instructions Transact-SQL sont répertoriées pour chacun de ces étapes. Exécutez les instructions Transact-SQL pour effectuer la tâche qui est mentionnée dans l'étape précédente.

1. Créer un distributeur, éditeurs et abonnés sur un ordinateur exécutant SQL Server. Pour ce faire, procédez comme suit :
   1. Créer deux bases de données :

      use master
      go
      
      create database test1
      go
      
      create database test2
      go
      

   2. Créez les tables entre qui ont une colonne IDENTITY avec l'ensemble d'options non de réplication :

      use test1
      go
      
      create table two_way_test1 
      (
      	pkcol		INTEGER PRIMARY KEY NOT NULL,
      	intcol		INTEGER IDENTITY(1,1) NOT FOR REPLICATION,
       	charcol		CHAR(100),
      	timestampcol 	TIMESTAMP
      )
      
      use test2
      go
      
      create table two_way_test2 
      (
      	pkcol 		INTEGER PRIMARY KEY NOT NULL,
      	intcol 		INTEGER IDENTITY(1000000000,1) NOT FOR REPLICATION,
       	charcol 	CHAR(100),
       	timestampcol 	TIMESTAMP
      )
      go

   3. Affecter une plage prédéfinie de valeurs pour la colonne de clé primaire afin que les valeurs sur les différents serveurs ne trouvent pas dans la même plage. Par exemple, vous pouvez appliquer 1 1 000 comme étendue de clé de la table two_way_test1 dans la base de données test1 et puis appliquer-2000 1001 comme étendue de clé de table two_way_test2 dans la base de données test2 . Pour cela, utilisez le code suivant :

      	-- Constraint to enforce a range of values between 1 and 1000 in database test1 
      use test1
      go
      
      alter table 
      	two_way_test1 
      with nocheck 
      add constraint 
      	checkprimcol check NOT FOR REPLICATION 
      	(
      		pkcol BETWEEN 1 and 1000
      	) 
      go 
      
      
      use test2
      go
      
      	-- Constraint to enforce a range of values between 1001 and 2000 in the database test2 
      
      alter table 
      	two_way_test2
      with nocheck 
      add constraint 
      	checkprimcol check NOT FOR REPLICATION 
      	(
      		pkcol BETWEEN 1001 and 2000
      	) 
      go 
      
      

2. Activer votre serveur en tant que le distributeur et créez une base de données de distribution :

   use master
   go
   sp_adddistributor @distributor = '<distributor name>' 
   go
   use master
   go
   sp_adddistributiondb @database='distribution'
   go

3. Activer tous les ordinateurs exécutant SQL Server qui appartiennent à la réplication en tant que éditeurs :

   use master
   go
   
   exec sp_adddistpublisher 
   	@publisher = '<Your Server Name>', 
   	@distribution_db ='distribution', 
   	@security_mode = 0, 
   	@login = 'sa', 
   	@password = 'sa',
   	@working_directory ='<Location of Directory>'

4. Activer toutes les bases d'identifié données pour la réplication :

   use master
   go
   
   exec sp_replicationdboption N'test1', N'publish', true
   go
   
   exec sp_replicationdboption N'test2', N'publish', true
   go
   

5. Créer des procédures stockées personnalisées pour INSERT, UPDATE et DELETE opérations sur toutes les bases de données pour appliquer les modifications sont apportées au cours de la réplication.
   
   note En règle générale, lorsque vous insérez une valeur dans une colonne IDENTITY, l'option IDENTITY_INSERT pour la table doit être activée. Cette tâche est obtenue à l'option non de réplication pour les agents de réplication entrant.
   
   Vous ne pouvez pas mettre à jour les valeurs dans la colonne IDENTITY. Par conséquent, lorsque vous mettez à jour les valeurs lors de la réplication, vous devez supprimer les anciennes valeurs et insérer les nouvelles valeurs. Pour créer des procédures stockées personnalisées, procédez comme suit :
   1. Create the custom stored procedures in the test1 database:

      use test1
      go
      
      -- INSERT Stored Procedure
      
      create procedure sp_ins_two_way_test1	
      	@pkcol int, 
      	@intcol int, 
      	@charcol char(100), 
      	@timestampcol timestamp,
      	@rowidcol uniqueidentifier
      as
      	insert into two_way_test1 
      	(
      		pkcol,
      		intcol,
      		charcol
      	) 
      	values
      	(
      		@pkcol, 
      		@intcol, 
      		@charcol
      	)
      go
      
      --UPDATE Stored Procedure
      
      create procedure sp_upd_two_way_test1	
      	@pkcol int, 
          	@intcol int, 
          	@charcol char(100), 
          	@timestampcol timestamp,
      	@rowidcol uniqueidentifier,
          	@old_pkcol int
      as
      	declare @x int
      	declare @y int
      	declare @z char(100)
       
      	select 
      		@x=pkcol, 
      		@y=intcol, 
      		@z=charcol 
      	from 
      		two_way_test1 
      	where 
      		pkcol = @pkcol
      
      
      
      	delete 
      		two_way_test1 
      	where 
      		pkcol=@pkcol
      
      
      
      	insert into two_way_test1 
      	(
      		pkcol, 
      		intcol, 
      		charcol
      	) 
      	values
      	(
      		case isnull(@pkcol,0) when 0 then @x else @pkcol end,
      		case isnull(@intcol,0) when 0 then @y else @intcol end,
      		case isnull(@charcol,'N') when 'N' then @z else @charcol end
      	)
      go
      
      --  DELETE Stored Procedure
      
      create procedure sp_del_two_way_test1 
      	@old_pkcol int
      as
      	delete 
      		two_way_test1 
      	where 
      		pkcol = @old_pkcol
      go
      
      

   2. Create the custom stored procedures in the test2 database:

      use test2
      go
      
      -- INSERT Stored Procedure
      
      create procedure sp_ins_two_way_test2	
      	@pkcol int, 
      	@intcol int, 
      	@charcol char(100), 
      	@timestampcol timestamp,
      	@rowidcol uniqueidentifier
      as
      	insert into two_way_test2 
      	(
      		pkcol,
      		intcol,
      		charcol
      	) 
      	values
      	(
      		@pkcol, 
      		@intcol, 
      		@charcol
      	)
      go
      
      --UPDATE Stored Procedure
      
      create procedure sp_upd_two_way_test2	
      	@pkcol int, 
          	@intcol int, 
          	@charcol char(100), 
          	@timestampcol timestamp,
      	@rowidcol uniqueidentifier,
          	@old_pkcol int
      as
      	declare @x int
      	declare @y int
      	declare @z char(100)
       
      	select 
      		@x=pkcol, 
      		@y=intcol, 
      		@z=charcol 
      	from 
      		two_way_test2 
      	where 
      		pkcol = @pkcol
      
      
      
      	delete 
      		two_way_test2 
      	where 
      		pkcol=@pkcol
      
      
      
      	insert into two_way_test2 
      	(
      		pkcol, 
      		intcol, 
      		charcol
      	) 
      	values
      	(
      		case isnull(@pkcol,0) when 0 then @x else @pkcol end,
      		case isnull(@intcol,0) when 0 then @y else @intcol end,
      		case isnull(@charcol,'N') when 'N' then @z else @charcol end
      	)
      go
      
      
      --  DELETE Stored Procedure
      
      create procedure sp_del_two_way_test2 
      	@old_pkcol int
      as
      	delete 
      		two_way_test2 
      	where 
      		pkcol = @old_pkcol
      go
      

6. Créer une publication transactionnelle et réintégration des articles à la composition dans le test1 et les bases de données test2 :

   --In the database test1.
   
   use test1
   go
   
   --  Adding the transactional publication.
   exec sp_addpublication 
   	@publication = N'two_way_pub_test1', 
   	@restricted = N'false',
   	@sync_method = N'native', 
   	@repl_freq = N'continuous',
   	@description = N'Transactional publication of database test1.',
   	@status = N'active', 
   	@allow_push = N'true', 
   	@allow_pull = N'true',
   	@allow_anonymous = N'false', 
   	@enabled_for_internet = N'false',
   	@independent_agent = N'false', 
   	@immediate_sync = N'false',
   	@allow_sync_tran = N'true', 
   	@autogen_sync_procs = N'true',
   	@retention = 72
   go
   
   exec sp_addpublication_snapshot 
   	@publication = N'two_way_pub_test1',
   	@frequency_type = 4,
   	@frequency_interval = 1, 
   	@frequency_relative_interval = 0,
   	@frequency_recurrence_factor = 1, 
   	@frequency_subday = 1,
   	@frequency_subday_interval = 0, 
   	@active_start_date = 0,
   	@active_end_date = 0, 
   	@active_start_time_of_day = 233000,
   	@active_end_time_of_day = 0
   go
   
   --  Adding the transactional articles.
   
   exec sp_addarticle 
   	@publication = N'two_way_pub_test1', 
   	@article = N'two_way_test1',
   	@source_owner = N'dbo', 
   	@source_object = N'two_way_test1',
   	@destination_table = N'two_way_test1', 
   	@type = N'logbased',
   	@creation_script = null, 
   	@description = null, 
   	@pre_creation_cmd = N'drop',
           @schema_option = 0x00000000000000F1, 
   	@status = 16,
   	@vertical_partition = N'false', 
   	@ins_cmd = N'CALL sp_ins_two_way_test2',
   	@del_cmd = N'CALL sp_del_two_way_test2',
   	@upd_cmd = N'CALL sp_upd_two_way_test2', 
   	@filter = null,
   	@sync_object = null
   go
   
   --  In the database test2
   use test2
   go
   
   --  Adding the transactional publication.
   
   exec sp_addpublication 
   	@publication = N'two_way_pub_test2', 
   	@restricted = N'false',
   	@sync_method = N'native', 
   	@repl_freq = N'continuous',
   	@description = N'Transactional publication of database test2',
   	@status = N'active', 
   	@allow_push = N'true', 
   	@allow_pull = N'true',
   	@allow_anonymous = N'false', 
   	@enabled_for_internet = N'false',
   	@independent_agent = N'false', 
   	@immediate_sync = N'false',
   	@allow_sync_tran = N'true', 
   	@autogen_sync_procs = N'true',
   	@retention = 72
   go
   
   exec sp_addpublication_snapshot 
   	@publication = N'two_way_pub_test2',
   	@frequency_type = 4,
   	@frequency_interval = 1, 
   	@frequency_relative_interval = 0,
   	@frequency_recurrence_factor = 1, 
   	@frequency_subday = 1,
   	@frequency_subday_interval = 0, 
   	@active_start_date = 0,
   	@active_end_date = 0, 
   	@active_start_time_of_day = 233000,
   	@active_end_time_of_day = 0
   go
   
   --  Adding the transactional articles.
   exec sp_addarticle 
   	@publication = N'two_way_pub_test2', 
   	@article = N'two_way_test2',
   	@source_owner = N'dbo', 
   	@source_object = N'two_way_test2',
   	@destination_table = N'two_way_test2', 
   	@type = N'logbased',
   	@creation_script = null, 
   	@description = null, 
   	@pre_creation_cmd = N'drop',
   	@schema_option = 0x00000000000000F1, 
   	@status = 16,
   	@vertical_partition = N'false', 
   	@ins_cmd = N'CALL sp_ins_two_way_test1',
   	@del_cmd = N'CALL sp_del_two_way_test1',
   	@upd_cmd = N'CALL sp_upd_two_way_test1', 
   	@filter = null,
   	@sync_object = null
   go
   

   EXEC sp_addarticle @publication = N 'two_way_pub_test2 », @ article = 'two_way_test2' N, @ source_owner = N'dbo », @ source_object = N 'two_way_test2 », @ destination_table = N 'two_way_test2 », @ type = N'logbased », @ creation_script = null, @ description = null, @ pre_creation_cmd = N'drop », @ schema_option = 0x00000000000000F1, @ état = 16, @ vertical_partition = N'false », @ ins_cmd = N'CALL sp_ins_two_way_test1 », @ del_cmd = N'CALL sp_del_two_way_test1 », @ upd_cmd = N'CALL sp_upd_two_way_test1 « @ filtre = null, @ sync_object = null aller
7. Activer les abonnés tous les serveurs qui participent à la réplication :

   exec sp_addsubscriber 
   	@subscriber = '<Your Server Name>', 
   	@login = '<login name>', 
   	@password = '<password>'
   go
   
   

8. Identifier une des bases de données comme l'abonné central. Créer des abonnements transactionnelles dans toutes les bases de données qui participent à la réplication afin que toutes les bases de données s'abonner à l'abonné central et l'abonné central s'abonne à tous les autres bases de données.
   
   Par exemple, dans ce scénario, la base de données test1 est l'abonné central. Créer abonnements transactionnelles dans la base de données test2 s'abonner à la composition à test1 et dans la base de données test1 s'abonner à la composition à test2 .
   
   note Créer les abonnements avec l'option LOOPBACK_DETECTION activée.
   
   Pour cela, utilisez le code suivant :

   --Adding the transactional subscription in test1.
   
   use test1
   go
   exec sp_addsubscription 
   	@publication = N'two_way_pub_test1', 
   	@article = N'all', 
   	@subscriber = '<Your Server Name>', 
   	@destination_db = N'test2', 
   	@sync_type = N'none', 
   	@status = N'active', 
   	@update_mode = N'sync tran', 
   	@loopback_detection = 'true'
   go
   
   -- Adding the transactional subscription in test2.
   
   use test2
   go
   exec sp_addsubscription 
   	@publication = N'two_way_pub_test2', 
   	@article = N'all', 
   	@subscriber = '<Your Server Name>', 
   	@destination_db = N'test1', 
   	@sync_type = N'none', 
   	@status = N'active', 
   	@update_mode = N'sync tran', 
   	@loopback_detection = 'true'
   go
   

note Vous pouvez également créer des procédures stockées personnalisées pour toutes les compositions en utilisant la procédure système stockée sp_scriptpublicationcustomprocs . Pour plus d'informations sur la procédure système stockée sp_scriptpublicationcustomprocs , consultez la rubrique « sp_scriptpublicationcustomprocs » dans la Server 2000 mise à jour documentation en ligne de SQL.

note L'Analyseur de requêtes SQL renvoie uniquement 256 caractères par colonne. Vous pouvez modifier cette option à la valeur maximale valeur autorisée.

Pour plus d'informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft : Pour plus d'informations sur l'implémentation de réplication transactionnelle bidirectionnelle dans SQL Server 7.0, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :