Nous avons mis en place une nouvelle replication !
toutefois une de nos procedure ne fonctionne plus au niveau de la commande
Truncate Table ???
Le delete marche mais du coup est beaucoup plus long ?
Existe t'il un delete sans ecriture dans le journal !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Rudi Bruchez
Christophe a écrit:
Nous avons mis en place une nouvelle replication ! toutefois une de nos procedure ne fonctionne plus au niveau de la commande Truncate Table ??? Le delete marche mais du coup est beaucoup plus long ? Existe t'il un delete sans ecriture dans le journal !
Une info pourquoi ?
Bonjour,
On ne peut pas faire un truncate sur une table publiée en réplication (je présume qu'elle est transactionnelle ?)... parce que simplement les suppressions ne seraient pas répercutées sur les subscribers, puisque l'opération n'est pas loguée. Si ta table est si peu importante qu'elle est tronquée dans un sp (probablement pour la reremplir complètement), pourquoi la répliquer ?
Si c'est le cas, une solution peut être d'enlever la table de la réplication, et de lancer la procédure qui la remplit sur les subscribers après modification des données source.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Christophe a écrit:
Nous avons mis en place une nouvelle replication !
toutefois une de nos procedure ne fonctionne plus au niveau de la commande
Truncate Table ???
Le delete marche mais du coup est beaucoup plus long ?
Existe t'il un delete sans ecriture dans le journal !
Une info pourquoi ?
Bonjour,
On ne peut pas faire un truncate sur une table publiée en réplication (je
présume qu'elle est transactionnelle ?)... parce que simplement les
suppressions ne seraient pas répercutées sur les subscribers, puisque
l'opération n'est pas loguée.
Si ta table est si peu importante qu'elle est tronquée dans un sp
(probablement pour la reremplir complètement), pourquoi la répliquer ?
Si c'est le cas, une solution peut être d'enlever la table de la
réplication, et de lancer la procédure qui la remplit sur les subscribers
après modification des données source.
Nous avons mis en place une nouvelle replication ! toutefois une de nos procedure ne fonctionne plus au niveau de la commande Truncate Table ??? Le delete marche mais du coup est beaucoup plus long ? Existe t'il un delete sans ecriture dans le journal !
Une info pourquoi ?
Bonjour,
On ne peut pas faire un truncate sur une table publiée en réplication (je présume qu'elle est transactionnelle ?)... parce que simplement les suppressions ne seraient pas répercutées sur les subscribers, puisque l'opération n'est pas loguée. Si ta table est si peu importante qu'elle est tronquée dans un sp (probablement pour la reremplir complètement), pourquoi la répliquer ?
Si c'est le cas, une solution peut être d'enlever la table de la réplication, et de lancer la procédure qui la remplit sur les subscribers après modification des données source.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Christophe
Oui c'est exactement ça ! c'est pas moi qui est fait ce choix, donc malheureusement je dois m'y plier ! on va dire que la replication gere l'envoi à tous les abonnés. ile ne veulent pas de procedure particuliere qui pourrait allez remplir les table sur les serveurs repliqués. Car comme ca la maintenance est plus simple !!
Donc... mais du coup je passe par un delete ! toute j'ai un nouveau probleme soumis plus haut.
il faut que le identity, reparte de zero ! toutefois je ne peux pas utiliser le dbcc checkident(matable, reseed, 0) car la procedure s'execute sur une base A et matable est sur une baseB donc dbcc checkident(mabase.dbo.matable, reseed, 0) ne fonctionne pas !
alors je me suis dit alter table comme dans la doc en ligne mais j'ai une erreur pourquoi la je ne sais pas je seche ? ALTER TABLE mabase.dbo.matable ALTER COLUMN uid IDENTITY (1,1)
voici le message d'erreur ? Syntaxe incorrecte vers le mot clé 'IDENTITY'.
je deviens fou comment les trucs qui on l'air les plus simples sont les plus compliqués !
alors j'ai trouvé avec ça ALTER TABLE tempac.dbo.maTable DROP COLUMN uid ALTER TABLE tempac.dbo.maTable ADD uid int NOT NULL identity(1,1)
mais j'ai peur que cela sorte mon champ de la replication ???
As tu une idée ?.
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de news:1v0mimx228d6r$.6ur9cvmu20fh$
Christophe a écrit:
> Nous avons mis en place une nouvelle replication ! > toutefois une de nos procedure ne fonctionne plus au niveau de la
commande
> Truncate Table ??? > Le delete marche mais du coup est beaucoup plus long ? > Existe t'il un delete sans ecriture dans le journal ! > > Une info pourquoi ?
Bonjour,
On ne peut pas faire un truncate sur une table publiée en réplication (je présume qu'elle est transactionnelle ?)... parce que simplement les suppressions ne seraient pas répercutées sur les subscribers, puisque l'opération n'est pas loguée. Si ta table est si peu importante qu'elle est tronquée dans un sp (probablement pour la reremplir complètement), pourquoi la répliquer ?
Si c'est le cas, une solution peut être d'enlever la table de la réplication, et de lancer la procédure qui la remplit sur les subscribers après modification des données source.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Oui c'est exactement ça !
c'est pas moi qui est fait ce choix, donc malheureusement je dois m'y plier
!
on va dire que la replication gere l'envoi à tous les abonnés.
ile ne veulent pas de procedure particuliere qui pourrait allez remplir les
table sur les serveurs repliqués.
Car comme ca la maintenance est plus simple !!
Donc...
mais du coup je passe par un delete !
toute j'ai un nouveau probleme soumis plus haut.
il faut que le identity, reparte de zero !
toutefois je ne peux pas utiliser le dbcc checkident(matable, reseed, 0)
car la procedure s'execute sur une base A et matable est sur une baseB
donc dbcc checkident(mabase.dbo.matable, reseed, 0) ne fonctionne pas !
alors je me suis dit alter table comme dans la doc en ligne mais j'ai une
erreur pourquoi la je ne sais pas je seche ?
ALTER TABLE mabase.dbo.matable ALTER COLUMN uid IDENTITY (1,1)
voici le message d'erreur ?
Syntaxe incorrecte vers le mot clé 'IDENTITY'.
je deviens fou comment les trucs qui on l'air les plus simples sont les plus
compliqués !
alors j'ai trouvé avec ça
ALTER TABLE tempac.dbo.maTable DROP COLUMN uid
ALTER TABLE tempac.dbo.maTable ADD uid int NOT NULL identity(1,1)
mais j'ai peur que cela sorte mon champ de la replication ???
As tu une idée ?.
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de
news:1v0mimx228d6r$.6ur9cvmu20fh$.dlg@40tude.net...
Christophe a écrit:
> Nous avons mis en place une nouvelle replication !
> toutefois une de nos procedure ne fonctionne plus au niveau de la
commande
> Truncate Table ???
> Le delete marche mais du coup est beaucoup plus long ?
> Existe t'il un delete sans ecriture dans le journal !
>
> Une info pourquoi ?
Bonjour,
On ne peut pas faire un truncate sur une table publiée en réplication (je
présume qu'elle est transactionnelle ?)... parce que simplement les
suppressions ne seraient pas répercutées sur les subscribers, puisque
l'opération n'est pas loguée.
Si ta table est si peu importante qu'elle est tronquée dans un sp
(probablement pour la reremplir complètement), pourquoi la répliquer ?
Si c'est le cas, une solution peut être d'enlever la table de la
réplication, et de lancer la procédure qui la remplit sur les subscribers
après modification des données source.
Oui c'est exactement ça ! c'est pas moi qui est fait ce choix, donc malheureusement je dois m'y plier ! on va dire que la replication gere l'envoi à tous les abonnés. ile ne veulent pas de procedure particuliere qui pourrait allez remplir les table sur les serveurs repliqués. Car comme ca la maintenance est plus simple !!
Donc... mais du coup je passe par un delete ! toute j'ai un nouveau probleme soumis plus haut.
il faut que le identity, reparte de zero ! toutefois je ne peux pas utiliser le dbcc checkident(matable, reseed, 0) car la procedure s'execute sur une base A et matable est sur une baseB donc dbcc checkident(mabase.dbo.matable, reseed, 0) ne fonctionne pas !
alors je me suis dit alter table comme dans la doc en ligne mais j'ai une erreur pourquoi la je ne sais pas je seche ? ALTER TABLE mabase.dbo.matable ALTER COLUMN uid IDENTITY (1,1)
voici le message d'erreur ? Syntaxe incorrecte vers le mot clé 'IDENTITY'.
je deviens fou comment les trucs qui on l'air les plus simples sont les plus compliqués !
alors j'ai trouvé avec ça ALTER TABLE tempac.dbo.maTable DROP COLUMN uid ALTER TABLE tempac.dbo.maTable ADD uid int NOT NULL identity(1,1)
mais j'ai peur que cela sorte mon champ de la replication ???
As tu une idée ?.
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de news:1v0mimx228d6r$.6ur9cvmu20fh$
Christophe a écrit:
> Nous avons mis en place une nouvelle replication ! > toutefois une de nos procedure ne fonctionne plus au niveau de la
commande
> Truncate Table ??? > Le delete marche mais du coup est beaucoup plus long ? > Existe t'il un delete sans ecriture dans le journal ! > > Une info pourquoi ?
Bonjour,
On ne peut pas faire un truncate sur une table publiée en réplication (je présume qu'elle est transactionnelle ?)... parce que simplement les suppressions ne seraient pas répercutées sur les subscribers, puisque l'opération n'est pas loguée. Si ta table est si peu importante qu'elle est tronquée dans un sp (probablement pour la reremplir complètement), pourquoi la répliquer ?
Si c'est le cas, une solution peut être d'enlever la table de la réplication, et de lancer la procédure qui la remplit sur les subscribers après modification des données source.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Rudi Bruchez
Christophe a écrit:
As tu une idée ?.
Je suis un peux confusionné par tout ça :) Mais les suggestions qui me viennent :
- tu peux inclure dans la réplication du code qui s'exécute sur chaque subscriber avant ou après l'exécution de la réplication - tu peux utiliser un job qui fait le travail, et par exemple avoir ton publisher comme master pour un job multi-serveurs, qui s'occuperait de reremplir ta table en faisant un reseed
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Christophe a écrit:
As tu une idée ?.
Je suis un peux confusionné par tout ça :) Mais les suggestions qui me
viennent :
- tu peux inclure dans la réplication du code qui s'exécute sur chaque
subscriber avant ou après l'exécution de la réplication
- tu peux utiliser un job qui fait le travail, et par exemple avoir ton
publisher comme master pour un job multi-serveurs, qui s'occuperait de
reremplir ta table en faisant un reseed
Je suis un peux confusionné par tout ça :) Mais les suggestions qui me viennent :
- tu peux inclure dans la réplication du code qui s'exécute sur chaque subscriber avant ou après l'exécution de la réplication - tu peux utiliser un job qui fait le travail, et par exemple avoir ton publisher comme master pour un job multi-serveurs, qui s'occuperait de reremplir ta table en faisant un reseed
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
SQLpro [MVP]
Christophe a écrit :
Oui c'est exactement ça ! c'est pas moi qui est fait ce choix, donc malheureusement je dois m'y plier ! on va dire que la replication gere l'envoi à tous les abonnés. ile ne veulent pas de procedure particuliere qui pourrait allez remplir les table sur les serveurs repliqués. Car comme ca la maintenance est plus simple !!
Donc... mais du coup je passe par un delete ! toute j'ai un nouveau probleme soumis plus haut.
il faut que le identity, reparte de zero ! toutefois je ne peux pas utiliser le dbcc checkident(matable, reseed, 0) car la procedure s'execute sur une base A et matable est sur une baseB donc dbcc checkident(mabase.dbo.matable, reseed, 0) ne fonctionne pas !
alors je me suis dit alter table comme dans la doc en ligne mais j'ai une erreur pourquoi la je ne sais pas je seche ? ALTER TABLE mabase.dbo.matable ALTER COLUMN uid IDENTITY (1,1)
Vous avez oublié de préciser le type de données INT de la colonne.
mais ce genre de manip sur une table en production est à haut risque car il faut en fait faire un script transactionné complexe pour débrancher toutes les contraintes afférente à cette colonne puis les remettre après modification de la colonne.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Christophe a écrit :
Oui c'est exactement ça !
c'est pas moi qui est fait ce choix, donc malheureusement je dois m'y plier
!
on va dire que la replication gere l'envoi à tous les abonnés.
ile ne veulent pas de procedure particuliere qui pourrait allez remplir les
table sur les serveurs repliqués.
Car comme ca la maintenance est plus simple !!
Donc...
mais du coup je passe par un delete !
toute j'ai un nouveau probleme soumis plus haut.
il faut que le identity, reparte de zero !
toutefois je ne peux pas utiliser le dbcc checkident(matable, reseed, 0)
car la procedure s'execute sur une base A et matable est sur une baseB
donc dbcc checkident(mabase.dbo.matable, reseed, 0) ne fonctionne pas !
alors je me suis dit alter table comme dans la doc en ligne mais j'ai une
erreur pourquoi la je ne sais pas je seche ?
ALTER TABLE mabase.dbo.matable ALTER COLUMN uid IDENTITY (1,1)
Vous avez oublié de préciser le type de données INT de la colonne.
mais ce genre de manip sur une table en production est à haut risque car
il faut en fait faire un script transactionné complexe pour débrancher
toutes les contraintes afférente à cette colonne puis les remettre après
modification de la colonne.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Oui c'est exactement ça ! c'est pas moi qui est fait ce choix, donc malheureusement je dois m'y plier ! on va dire que la replication gere l'envoi à tous les abonnés. ile ne veulent pas de procedure particuliere qui pourrait allez remplir les table sur les serveurs repliqués. Car comme ca la maintenance est plus simple !!
Donc... mais du coup je passe par un delete ! toute j'ai un nouveau probleme soumis plus haut.
il faut que le identity, reparte de zero ! toutefois je ne peux pas utiliser le dbcc checkident(matable, reseed, 0) car la procedure s'execute sur une base A et matable est sur une baseB donc dbcc checkident(mabase.dbo.matable, reseed, 0) ne fonctionne pas !
alors je me suis dit alter table comme dans la doc en ligne mais j'ai une erreur pourquoi la je ne sais pas je seche ? ALTER TABLE mabase.dbo.matable ALTER COLUMN uid IDENTITY (1,1)
Vous avez oublié de préciser le type de données INT de la colonne.
mais ce genre de manip sur une table en production est à haut risque car il faut en fait faire un script transactionné complexe pour débrancher toutes les contraintes afférente à cette colonne puis les remettre après modification de la colonne.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Christophe
Oui je sais tout ca
toutefois je confirme meme avec le type que j'ai juste oublié de recopier le message est le meme ! ALTER TABLE mabase.dbo.matable ALTER COLUMN uid INT IDENTITY (1,1) Syntaxe incorrecte vers le mot clé 'IDENTITY'.
voila j'ai fais du code pour changer drop la colone et la refaire via un add uid int identity(1,1) mais je preseume que si la colone et sous transaction, meme si je la refais avec le meme nom cela ne se repliquera plus si ????
"SQLpro [MVP]" a écrit dans le message de news:
Christophe a écrit : > Oui c'est exactement ça ! > c'est pas moi qui est fait ce choix, donc malheureusement je dois m'y
plier
> ! > on va dire que la replication gere l'envoi à tous les abonnés. > ile ne veulent pas de procedure particuliere qui pourrait allez remplir
les
> table sur les serveurs repliqués. > Car comme ca la maintenance est plus simple !! > > Donc... > mais du coup je passe par un delete ! > toute j'ai un nouveau probleme soumis plus haut. > > il faut que le identity, reparte de zero ! > toutefois je ne peux pas utiliser le dbcc checkident(matable, reseed, 0) > car la procedure s'execute sur une base A et matable est sur une baseB > donc dbcc checkident(mabase.dbo.matable, reseed, 0) ne fonctionne pas ! > > > alors je me suis dit alter table comme dans la doc en ligne mais j'ai
une
> erreur pourquoi la je ne sais pas je seche ? > ALTER TABLE mabase.dbo.matable ALTER COLUMN uid IDENTITY (1,1)
Vous avez oublié de préciser le type de données INT de la colonne.
mais ce genre de manip sur une table en production est à haut risque car il faut en fait faire un script transactionné complexe pour débrancher toutes les contraintes afférente à cette colonne puis les remettre après modification de la colonne.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Oui je sais tout ca
toutefois je confirme meme avec le type que j'ai juste oublié de recopier le
message est le meme !
ALTER TABLE mabase.dbo.matable ALTER COLUMN uid INT IDENTITY (1,1)
Syntaxe incorrecte vers le mot clé 'IDENTITY'.
voila j'ai fais du code pour changer drop la colone et la refaire via un add
uid int identity(1,1)
mais je preseume que si la colone et sous transaction,
meme si je la refais avec le meme nom cela ne se repliquera plus si ????
"SQLpro [MVP]" <brouardf@club-internet.fr> a écrit dans le message de
news:urcocZujGHA.836@TK2MSFTNGP02.phx.gbl...
Christophe a écrit :
> Oui c'est exactement ça !
> c'est pas moi qui est fait ce choix, donc malheureusement je dois m'y
plier
> !
> on va dire que la replication gere l'envoi à tous les abonnés.
> ile ne veulent pas de procedure particuliere qui pourrait allez remplir
les
> table sur les serveurs repliqués.
> Car comme ca la maintenance est plus simple !!
>
> Donc...
> mais du coup je passe par un delete !
> toute j'ai un nouveau probleme soumis plus haut.
>
> il faut que le identity, reparte de zero !
> toutefois je ne peux pas utiliser le dbcc checkident(matable, reseed, 0)
> car la procedure s'execute sur une base A et matable est sur une baseB
> donc dbcc checkident(mabase.dbo.matable, reseed, 0) ne fonctionne pas !
>
>
> alors je me suis dit alter table comme dans la doc en ligne mais j'ai
une
> erreur pourquoi la je ne sais pas je seche ?
> ALTER TABLE mabase.dbo.matable ALTER COLUMN uid IDENTITY (1,1)
Vous avez oublié de préciser le type de données INT de la colonne.
mais ce genre de manip sur une table en production est à haut risque car
il faut en fait faire un script transactionné complexe pour débrancher
toutes les contraintes afférente à cette colonne puis les remettre après
modification de la colonne.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
toutefois je confirme meme avec le type que j'ai juste oublié de recopier le message est le meme ! ALTER TABLE mabase.dbo.matable ALTER COLUMN uid INT IDENTITY (1,1) Syntaxe incorrecte vers le mot clé 'IDENTITY'.
voila j'ai fais du code pour changer drop la colone et la refaire via un add uid int identity(1,1) mais je preseume que si la colone et sous transaction, meme si je la refais avec le meme nom cela ne se repliquera plus si ????
"SQLpro [MVP]" a écrit dans le message de news:
Christophe a écrit : > Oui c'est exactement ça ! > c'est pas moi qui est fait ce choix, donc malheureusement je dois m'y
plier
> ! > on va dire que la replication gere l'envoi à tous les abonnés. > ile ne veulent pas de procedure particuliere qui pourrait allez remplir
les
> table sur les serveurs repliqués. > Car comme ca la maintenance est plus simple !! > > Donc... > mais du coup je passe par un delete ! > toute j'ai un nouveau probleme soumis plus haut. > > il faut que le identity, reparte de zero ! > toutefois je ne peux pas utiliser le dbcc checkident(matable, reseed, 0) > car la procedure s'execute sur une base A et matable est sur une baseB > donc dbcc checkident(mabase.dbo.matable, reseed, 0) ne fonctionne pas ! > > > alors je me suis dit alter table comme dans la doc en ligne mais j'ai
une
> erreur pourquoi la je ne sais pas je seche ? > ALTER TABLE mabase.dbo.matable ALTER COLUMN uid IDENTITY (1,1)
Vous avez oublié de préciser le type de données INT de la colonne.
mais ce genre de manip sur une table en production est à haut risque car il faut en fait faire un script transactionné complexe pour débrancher toutes les contraintes afférente à cette colonne puis les remettre après modification de la colonne.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Christophe
Alors ils ne veulent pas etre completement dependant d'une personne. cela dit je peux leur amener des solutions annexes comme tu viens de me les dire. Toutefois la Replication est un sujet complexe que je decouvre depuis peut alors je ne connais pas bien toute les possibilités offertes !
Peux tu me decrire comment je peux mettre du code qui sera executé apres ou avant la replication sur les clients ? ou me dire ou je peux rechercher des infos la dessus .
Merci par avance !
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de news:1kamisqxt9uj7.1o5fc57kjw626$
Christophe a écrit:
> As tu une idée ?.
Je suis un peux confusionné par tout ça :) Mais les suggestions qui me viennent :
- tu peux inclure dans la réplication du code qui s'exécute sur chaque subscriber avant ou après l'exécution de la réplication - tu peux utiliser un job qui fait le travail, et par exemple avoir ton publisher comme master pour un job multi-serveurs, qui s'occuperait de reremplir ta table en faisant un reseed
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Alors ils ne veulent pas etre completement dependant d'une personne.
cela dit je peux leur amener des solutions annexes comme tu viens de me les
dire.
Toutefois la Replication est un sujet complexe que je decouvre depuis peut
alors je ne connais pas bien toute les possibilités offertes !
Peux tu me decrire comment je peux mettre du code qui sera executé apres ou
avant la replication sur les clients ?
ou me dire ou je peux rechercher des infos la dessus .
Merci par avance !
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de
news:1kamisqxt9uj7.1o5fc57kjw626$.dlg@40tude.net...
Christophe a écrit:
> As tu une idée ?.
Je suis un peux confusionné par tout ça :) Mais les suggestions qui me
viennent :
- tu peux inclure dans la réplication du code qui s'exécute sur chaque
subscriber avant ou après l'exécution de la réplication
- tu peux utiliser un job qui fait le travail, et par exemple avoir ton
publisher comme master pour un job multi-serveurs, qui s'occuperait de
reremplir ta table en faisant un reseed
Alors ils ne veulent pas etre completement dependant d'une personne. cela dit je peux leur amener des solutions annexes comme tu viens de me les dire. Toutefois la Replication est un sujet complexe que je decouvre depuis peut alors je ne connais pas bien toute les possibilités offertes !
Peux tu me decrire comment je peux mettre du code qui sera executé apres ou avant la replication sur les clients ? ou me dire ou je peux rechercher des infos la dessus .
Merci par avance !
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de news:1kamisqxt9uj7.1o5fc57kjw626$
Christophe a écrit:
> As tu une idée ?.
Je suis un peux confusionné par tout ça :) Mais les suggestions qui me viennent :
- tu peux inclure dans la réplication du code qui s'exécute sur chaque subscriber avant ou après l'exécution de la réplication - tu peux utiliser un job qui fait le travail, et par exemple avoir ton publisher comme master pour un job multi-serveurs, qui s'occuperait de reremplir ta table en faisant un reseed
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Rudi Bruchez
Christophe a écrit:
Toutefois la Replication est un sujet complexe que je decouvre depuis peut alors je ne connais pas bien toute les possibilités offertes !
Peux tu me decrire comment je peux mettre du code qui sera executé apres ou avant la replication sur les clients ? ou me dire ou je peux rechercher des infos la dessus .
Sujet complexe en effet.
Tu peux : 1) répliquer l'exécution d'une procédure stockée. Dans les options de l'article, quand c'est une procédure stockée, tu devrais avoir la possibilité d'indiquer que tu veux répliquer le schéma seulement, ou l'exécution. Tu as un article sur le sujet ici : http://www.samspublishing.com/articles/article.asp?p43672 Je n'ai pas d'expérience sur cette méthode, je ne sais pas si cela répond à ton besoin.
2) indiquer du code avant et après avoir déployé un snapshot, dans l'onglet snapshot des paramètres d'une publication. Mais il s'agit uniquement du déploiement d'un snapshot et non des transactions.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Christophe a écrit:
Toutefois la Replication est un sujet complexe que je decouvre depuis peut
alors je ne connais pas bien toute les possibilités offertes !
Peux tu me decrire comment je peux mettre du code qui sera executé apres ou
avant la replication sur les clients ?
ou me dire ou je peux rechercher des infos la dessus .
Sujet complexe en effet.
Tu peux :
1) répliquer l'exécution d'une procédure stockée. Dans les options de
l'article, quand c'est une procédure stockée, tu devrais avoir la
possibilité d'indiquer que tu veux répliquer le schéma seulement, ou
l'exécution. Tu as un article sur le sujet ici :
http://www.samspublishing.com/articles/article.asp?p43672
Je n'ai pas d'expérience sur cette méthode, je ne sais pas si cela répond à
ton besoin.
2) indiquer du code avant et après avoir déployé un snapshot, dans l'onglet
snapshot des paramètres d'une publication. Mais il s'agit uniquement du
déploiement d'un snapshot et non des transactions.
Toutefois la Replication est un sujet complexe que je decouvre depuis peut alors je ne connais pas bien toute les possibilités offertes !
Peux tu me decrire comment je peux mettre du code qui sera executé apres ou avant la replication sur les clients ? ou me dire ou je peux rechercher des infos la dessus .
Sujet complexe en effet.
Tu peux : 1) répliquer l'exécution d'une procédure stockée. Dans les options de l'article, quand c'est une procédure stockée, tu devrais avoir la possibilité d'indiquer que tu veux répliquer le schéma seulement, ou l'exécution. Tu as un article sur le sujet ici : http://www.samspublishing.com/articles/article.asp?p43672 Je n'ai pas d'expérience sur cette méthode, je ne sais pas si cela répond à ton besoin.
2) indiquer du code avant et après avoir déployé un snapshot, dans l'onglet snapshot des paramètres d'une publication. Mais il s'agit uniquement du déploiement d'un snapshot et non des transactions.
