Discussion :

[Richard_35]

Bonjour à tous,

Nous venons de migrer notre base dorsale Access vers SQL Server 2008 express et tout s'est bien passé. La base frontale reste sous Access (.mde).

Je tente de mettre en place un environnement de développement confortable afin de pouvoir travailler sur une base de développement (étant la copie de la base réelle à un instant donné) et, ensuite, copier les évolutions de la base de développement sur la base de production, sans avoir à tenir à jour une liste des évolutions effectuées.

Ne pouvons-nous pas dissocier les tables, d'une part, des procédures stockées, vues et fonctions, d'autre part, afin de ne pas les perdre lors des sauvegardes/restaurations ?

En effet, la structure des tables s'effectue toujours sur la base de production (ajout de champ, principalement) et jamais sur la base de développement, alors que la création/modification des procédures stockées, vues et fonctions s'effectue toujours sur la base de développement et jamais sur base de production.

Il faudrait pouvoir :
- copier les tables (structures et données) de l'environnement de production vers l'environnement de développement afin de développer à partir des tables à jour ;
- copier les procédures stockées et/ou les vues et/ou les fonctions de l'environnement de développement vers l'environnement de production afin que les utilisateurs bénéficient des évolutions.

Merci d'avance de votre aide,
Richard.

[SQLpro]

Ne pouvons-nous pas dissocier les tables, d'une part, des procédures stockées, vues et fonctions, d'autre part, afin de ne pas les perdre lors des sauvegardes/restaurations ?

Comme son nom l'indique une procédure stockée est stockée dans la base (table système) la sauvegarde d'une base comporte donc tout : les tables, les vues, les données, les procédures, les fonctions, les déclencheurs....

En effet, la structure des tables s'effectue toujours sur la base de production (ajout de champ, principalement) et jamais sur la base de développement, alors que la création/modification des procédures stockées, vues et fonctions s'effectue toujours sur la base de développement et jamais sur base de production.

Mauvaise pratique, car vous n'êtes pas à l'abri d'une fausse manip qui corrompe vos données ! De plus, compte tenu de la journalisation des opérations de DDL, vous risquez de saturer inopinément le JT.

Il faudrait pouvoir :
- copier les tables (structures et données) de l'environnement de production vers l'environnement de développement afin de développer à partir des tables à jour ;

Si vous utilisez un outlde modélisation comme Power AMC, ce dernier est capable de faire des script SQL différentiel (mise à jour de l'architecture de la base) et de contenir l'état de votre base dans ses différentes versions.

- copier les procédures stockées et/ou les vues et/ou les fonctions de l'environnement de développement vers l'environnement de production afin que les utilisateurs bénéficient des évolutions.

Il vaudrait mieux que ces opérations soient faites conjointement avec les modif de structures, l'une pouvant avoir besoin de l'autre !

A +

[Richard_35]

Bonjour SQLpro,

Merci de ta réponse.

Comme son nom l'indique une procédure stockée est stockée dans la base (table système) la sauvegarde d'une base comporte donc tout : les tables, les vues, les données, les procédures, les fonctions, les déclencheurs....

OK, j'avais bien compris que si cette dissociation est possible, ce n'est pas la sauvegarde/restauration qui convient. Néanmoins, je pense que tu as compris l'esprit de mon besoin.

Mauvaise pratique, car vous n'êtes pas à l'abri d'une fausse manip qui corrompe vos données ! De plus, compte tenu de la journalisation des opérations de DDL, vous risquez de saturer inopinément le JT.

Je comprends. Je viens d'un système où les ajouts de champs dans une table étaient compliqués à effectuer, c'est pourquoi j'apprécie cette fonctionnalité "temps réel". Effectivement, c'est une manoeuvre toujours délicate à effectuer : elle doit donc rester limitée au responsable BD. A noter que je n'a jamais eu aucun problème avec cette opération (test éventuel préalable sur une base de test).
Quelle serait, selon toi, la procédure à appliquer pour ajouter un champ dans une table ?

Si vous utilisez un outlde modélisation comme Power AMC, ce dernier est capable de faire des script SQL différentiel (mise à jour de l'architecture de la base) et de contenir l'état de votre base dans ses différentes versions.

Non, je n'utilise pas d'outil de modélisation.

Il vaudrait mieux que ces opérations soient faites conjointement avec les modif de structures, l'une pouvant avoir besoin de l'autre !

Tu as raison. Il s'agit de notre responsabilité (gestionnaire BD/développeurs) de coordonner ces opérations : nous savons faire.

Visiblement, un script pourrait faire l'affaire :
script 1 :
copie des tables (structures et données) de l'environnement de production vers l'environnement de développement ;

script 2 :
copier les procédures stockées, vues et fonctions de l'environnement de développement vers l'environnement de production.

Si tu as une piste pour exploiter les tables "système" et écrire ces 2 scripts, je suis preneur.

Merci de ton (votre) aide,
Richard.

[SQLpro]

Visiblement, un script pourrait faire l'affaire :
script 1 :
copie des tables (structures et données) de l'environnement de production vers l'environnement de développement ;

Non : rapatrier une sauvegarde de la production vers le serveur de test (ceci peut être automatisé nuitamment par le biais de l'agent SQL).

script 2 :
copier les procédures stockées, vues et fonctions de l'environnement de développement vers l'environnement de production.

Ce qu'un outil de modélisation comme Power AMC, vous facilite grandement en calculant des scripts différentiels, comme par exemple comment changer le type de données d'une colonne en préservant les informations de la table...
A lire : http://sqlpro.developpez.com/cours/s...e=partie2#L7.6

Si tu as une piste pour exploiter les tables "système" et écrire ces 2 scripts, je suis preneur.

Il y a plus de 300 tables systèmes !!!!!!!!!!!!!!!!!!!!!!!!

A +

[Richard_35]

Bonjour SQLPro,

Je reprends, un peu tard, le fil de ce fil... désolé.

Il y a plus de 300 tables systèmes !!!!!!!!!!!!!!!!!!!!!!!!

Je comprends et c'est l'objet de la difficulté : parmis tous les contributeurs, peut-être y-en-a-t-il un qui a déjà été confronté à cette recherche ?

Le script 1 doit effectuer les opérations suivantes pour une base EXP :
- liste de tous les objets "tables" de la base EXP (à partir d'une table système) ;
- copie de tous les éléments de cette liste de la base EXP vers la base DEV.

Le script 2 doit effectuer les opérations suivantes pour une base EXP :
- liste de tous les objets "procédures stockées", "vues" et "fonctions" de la base DEV (à partir d'une table système) ;
- copie de tous les éléments de cette liste de la base DEV vers la base EXP.

Reste à traduire ces scripts en langage SQL.

Sinon, en effectuant quelques recherches, je suis tombé sur ce freeware bien sympathique (mais limité) que je vous laisse découvrir :http://www.sqldbtools.com/

Merci d'avance de votre aide,
Richard.

[soazig]

Bonjour,
Sur un projet, nous avons aussi utilisé open dbdiff pour scripter les modifications de tables, et un outil maison pour les procédures stockées, mais Open DBdiff s'en occupe aussi.
http://opendbiff.codeplex.com/Wikipage
Personnellement, je crée moi même les modifications de tables, et je liste les PS modifiées. J'ai un outil maison qui à partir de la liste crée le script de création des PS, mais sinon un simple sp_helptext peut suffire.

A +
Soazig

[Richard_35]

Bonjour soazig et SQLpro,

Désolé pour le retard.
J'ai une bonne piste par open dbdiff (non encore en route).
Je considère ce post comme résolu.

Merci beaucoup,
Richard.