Bonjour à tout le monde,
 
j'ai une base de données sqlserver 2005 express.
Je développe une application C# qui utilise cette base de données.  
Lorsque je fais des modifications dans mon application, je dois envoyer une mise à jour chez le client. Mais j'ai effectué des changements dans ma base de données aussi.
Alors voici ma question : comment mettre à jour le schéma de la base de données du client selon les modifications que j'ai fait sur ma base de données, SANS ECRASER OU PERDRE des données du client.
J'ai essayer d'utiliser le générateur de script de sql server 2005 pour qu'il me fasse des alter table là où il a lieu d'en avoir, mais ça ne change absolument rien.
 
 
Merci d'avance pour votre aide qui me sera plus que précieuse.

Ca dépend surtout des modifications apportées.
 
Sinon, dans tous les cas, il vaut mieux écrire ton script de mise à jour à la main. En effet, le générateur de scripts est bien gentil, mais lorsque tu as des dépendances en cascade complexes, il a parfois du mal et le script plante au milieu. Ensuite c'est la galère pour retrouver les parties qui n'ont pas fonctionné...

Ok, donc il me reste à bien tout analyser à chaque fois et faire mon script de mise à jour à la main.
Tu aurais éventuellement des conseils à me donner à ce propos? Je n'ai jamais touché aux mises à jour de schéma de DB.
 
Et merci déjà pour ton aide

Commencer par ne plus passer par la GUI pour faire les modifs dans la base : tu fais tout par script, et tu consignes chaque modification dans un fichier que tu pourras relivrer au client.

Ok, je vais m'y mettre de ce pas.
Je n'ai jamais fais de script de modif de base de données. Ce n'est pas bien compliqué j'imagine.  
Mettre des if not exists là où il faut, et des alter table aussi? Il y a quelque chose de bien spécifique à savoir dans la création de ces scripts?

logiquement, les if exists t'en auras pas trop besoin, puisque "logiquement" le script ne doit tourner qu'une fois chez le client, et tu est censé savoir ce qu'il y a chez le client
tu peux les mettre, mais ce n'est pas obligatoire.
 
sinon, ouais, tu vas t'amuser à coup de alter, de drop et de create.
 
sinon, là y'a rien qui me vient niveau "trucs spécifiques".
 
faut bien mettre des GO après chaque instruction qui modifie le schéma, à part ça non.
 
attention : une modif n'est pas rollbackable. donc travaille toujours dans une base de test avant de faire les modifs réellement. parceque si tu croûtes ton environnement de dev tu vas être vert après

Encore une dernière chose.
Comme tu dis, je suis censé savoir ce qu'il y a chez le client, mais à moins de faire une copie de la db avant de faire des nouvelles modifs, y a-t-il un moyen de sauvegarder son schéma simplement pour pouvoir faire les bonnes modifs?
 
Merci d'avance pour ta réponse et déjà merci du temps que tu as bien voulu me consacrer.
Ca m'éclaircit très bien.

C'est bien simple : logiquement, il ne doit pas faire de modifs sur la base sans te prévenir, puisqu'à priori c'est toi qui gère l'application qui utilise la base.
Si au contraire, ton appli se greffe sur une autre appli qui gère la base, alors tu ne dois pas modifier la base du client : tu dois en créer une seconde, et travailler avec des DBLINK afin de la lier au modèle existant (en travaillant avec des vues et autres objets dynamiques, tu peux rendre la chose totalement transparante).
 
Je pars du principe donc que c'est toi et toi seul qui gère le modèle de la base. A ce moment, tu dois avoir chez toi au moins trois bases de données différentes :
- Une copie de la base actuellement en production chez le client. Tu appliqueras dessus tes différents patchs au moment de la livraison.
- Une version de développement de la base : la base dans laquelle tu travailles.
- Une version de test, qui te permet de valider tes patches avant l'envoi au client, ainsi que valider le fonctionnement de l'application avant la mise en production.
 
Pour récupérer une version de la base du client, rien de plus simple : SQL Server dispose d'une GUI simplissime pour faire un backup d'une base. Backup la base en ne prenant que le modèle et les infos, mais pas les profils utilisateurs ni les utilisateurs. Il ne te reste plus qu'à restaurer ce backup sur ton serveur de développement.

Et bien voilà qui est très clair.
 
Je te remercie beaucoup pour ton aide précieuse.
 
A+

Bonjour,
une question supplémentaire : je suis dans le même cas, mais les modifications que je dois gérer impacte également les clés primaires qui sont actuellement définies comme des auto incréments.
Existe t il une solution efficace permettant de gérer les manipulations de clés primaires / étrangères ? Je pense notamment aux problèmes de correspondance...

Y'a pas de solution miracle.
 
Il faut faire avec le peu qu'il y a :
- Activer/Désactiver l'auto-incrément
- Activer/Désactiver les clés étrangères
- Récupérer le dernier ID créé : select scope_identity()
- Forcer/Interdire l'insertion de valeurs dans la colonne auto-incrément : set identity off / set identity on