Discussion :

[astur2000]

Bonjour,

Je suis débutant en SQL server 2005 et voici mon probleme.
Nous developpons actuellement un application Cognos planning qui stocke ses données dans un base SQL server. Ces données sont enregistrés sur une base SQL server lorsqu'on effectue une publication dans l'appli. Lors de la publication un table spécifique est mise à jour pour indiquer comment c'est passé la publication(succeed, failed , etc...) On souhaite pouvoir effectuer du reporting sur les tables de cognos planning mais pas directement sur celles-ci mais plutot sur une copie de celles-ci pour eviter que si la publication echoue on se retrouve avec des tables partiellement mise à jour. Bref je dois créer un trigger qui se declenche lorsqu'il y a une publication et en cas de succées il copie toutes les tables du schéma dans un autre schéma.
Pour le trigger je pense avoir trouver par contre je ne sais pas du tout comment copier toutes les tables d'un schema dans un autre.
Voici ce que j'ai commencé à ecrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
CREATE TRIGGER test1 ON dbo.P_JOB
AFTER INSERT
AS
DECLARE @jobtype varchar(250),
   @jobstate varchar(250)
SELECT @jobtype = job.jobtypeid , @jobstate = job.jobstateid
FROM  dbo.P_JOB AS job 
GROUP BY job.jobtypeid , job.jobstateid, job.lastcompletiondt
HAVING job.lastcompletiondt=max(job.lastcompletiondt)
IF @creditrating = 'REPORTING_PUBLISH' and @jobstate='COMPLETE'
BEGIN
 
 
END
GO

Voilà si quelqu'un peut me mettre sur une piste pour la suite ça serait trés gentil.

D'avance merci

[elsuket]

Bonjour,

comment copier toutes les tables d'un schema dans un autre.

Ne vous cassez pas la tête à copier les tables une par une : comme vous êtes sous SQL Server 2005, il vous suffit de créer une capture instantanée de base de données, puisque vous n'avez besoin de vos données qu'en lecture seule.

Je ne suis sûr que vous ayez besoin d'exécuter cela dans un trigger: si vous pouvez appeler une procédure stockée de création de la capture de base de données à partir de la procédure stockée de mise à jour de la table dbo.P_JOB, c'est amplement suffisant

@++

[astur2000]

Merci pour la réponse, le fait que le snapshot ne soit qu'en lecture seule ne devrait pas poser de probleme effectivement.

J'ai néanmoins quelques petites question concernant les snapshots. Peut-on faire un snapshot que d'un schéma et non d'une BD entière. Le snapshot aura t-il les même temps de reponse qu'une BD classique?

dernière question mais je me doute que cela n'est pas possible: a terme on aurait souhaité faire seulement une mise à jour de la copie du schéma(c'est à dire ne faire la copie que des nouvelles tables et des tables qui ont été modifiées) pour eviter que la copie ne prenne trop de temps. J'ai cru comprendre que cela est possible avec un BACKUP différentiel mais est-ce possible avec un snapshot?

Cdt

[elsuket]

Peut-on faire un snapshot que d'un schéma et non d'une BD entière

On ne peut pas faire une capture d'un schéma, c'est la base de données ou rien

. Le snapshot aura t-il les même temps de reponse qu'une BD classique?

Il n'y a pas de raison que cela fonctionne moins bien.
Malheureusement je n'ai jamais eu l'occasion de tester cela.

a terme on aurait souhaité faire seulement une mise à jour de la copie du schéma(c'est à dire ne faire la copie que des nouvelles tables et des tables qui ont été modifiées) pour eviter que la copie ne prenne trop de temps. J'ai cru comprendre que cela est possible avec un BACKUP différentiel mais est-ce possible avec un snapshot?

Attention, vous confondez plusieurs choses : lorsqu'on réalise une sauvegarde différentielle, on sauvegarde toutes les pages qui ont été modifiées dans la base de données depuis la dernière sauvegarde complète.
Cette opération a lieu sur l'ensemble de la base de données : on ne peut pas sauver une partie de la base de données, car on perdrait alors son intégrité !

Il en est de même pour les captures instantanées de base de données : on prend une photo de la base de données à un moment donné, et on ne peut la prendre que dans sa globalité, sinon il y aurait incohérence des données.

Maintenant que vous avez décrit plus exactement ce que vous souhaitez faire, vous êtes effectivement obligé de créer vos tables de travail, par exemple dans un autre schéma, ce qui me paraît être une bonne idée.

Pour "mesurer" ensuite l'écart de données entre vos table de travail, vous aurez besoin sur votre table source d'une clé primaire.
Sans cela il vous sera impossible d'effectuer la mise à jour.
Une fois que vous aurez réalisé les mises à jour dans les tables copie, pour mettre à jour les tables maître, il vous faudra exécuter les deux requêtes type suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
UPDATE monSchemaSource.maTable
SET nom = CIBLE.nom
FROM monSchemaCible.maTable AS CIBLE
JOIN monSchemaSource.maTable AS SOURCE
	ON CIBLE.IDCible = SOURCE.IDSource
 
INSERT INTO monSchemaSource.maTable
	SELECT PK_ID, colonnes
	FROM monSchemaCible.maTable
EXCEPT
	SELECT PK_IDcolonnes
	FROM monSchemaSource.maTable

Cela suppose qu'aucune mise à jour n'est effectuée sur la table source pendant que vous réalisez la mise à jour ...

@++