Mise à jour de la database SQL Server à partir des scripts SQL lors de l'installation

Notre scénario actuel est comme ceci:

nous avons une database existante qui doit être mise à jour pour chaque nouvelle version que nous installons
nous devons le faire à partir de scripts SQL individuels (nous ne pouvons pas utiliser les outils DB compare / diff)
l'installation devrait exécuter les scripts SQL aussi automatiquement que possible
l'installation ne doit exécuter que les scripts SQL qui n'ont pas été exécutés auparavant
l'installation doit vider un rapport du script qui a couru et qui n'a pas
l'installation est faite par le personnel informatique du client qui n'est pas terriblement informé SQL

Que ce soit une bonne configuration ou non est au-delà de cette question – en ce moment, prenez cela comme un absolu donné – nous ne pouvons pas changer cela cette année ou l'année prochaine à coup sûr.

À l'heure actuelle, nous utilisons un «gestionnaire de mise à jour de database» de chez nous – cela fonctionne, la plupart du time, mais la quantité de travail nécessaire pour le rendre totalement automatique semble être trop lourde.

Oui, je connais SQLCMD – mais cela semble un peu "trop basique" – ou pas?

Est-ce que quelqu'un là-bas fait la même chose? Si c'est le cas, comment? Utilisez-vous un outil et si oui, lequel?

Merci pour toute idée, consortingbution, reflection, pointeur sur les outils ou les methods que vous utilisez!

Marc

J'ai une situation similaire. Nous maintenons les scripts d'object de database dans le contrôle de version. Pour une relasase, les versions appropriées sont marquées et extraites du contrôle de version. Un script personnalisé concatène les scripts d'objects individuels en un set de Create_DB, Ceate_DB_Tables, CreateDB Procs, … Lors d'un travail antérieur, j'ai utilisé des files batch créés manuellement et OSQL pour exécuter les scripts de création / mise à jour de database.

Dans ma position actuelle, nous avons installé InstallSheild avec un "Install Helper" personnalisé écrit en C ++ pour appeler les scripts de database en utilisant SqlCmd.

En outre, comme CK, nous avons la table SchemaVersion dans chaque database. La table contient des informations sur les versions de l'application et de la database. La verison de schéma est juste un integer qui devient incrémant avec chaque version.

Cela semble compliqué mais ça marche plutôt bien.

J'ai une configuration similaire à ceci et ceci est ma solution:

Avoir une table dbVersion qui stocke un numéro de version et un timbre datetime. Avoir un fodler où les scripts sont stockés avec un système de numérotation, par exemple x [000] Avoir une application console / GUI qui s'exécute dans le cadre de l'installation et compare le numéro de dbVersion avec les numéros des files. Exécutez chaque nouveau file dans l'ordre, dans une transaction.

Cela a fonctionné pour nous pendant un certain time.

Une partie de notre application GUI permet à l'user de choisir quelle database mettre à jour, puis une certaine string # dbname # dans le script est remplacé par le nom de la database qu'ils choisissent.

Vous pouvez essayer Wizardby : il vous permet de spécifier les changements de database de façon incrémentielle et il va appliquer ces changements de manière très contrôlée. Vous devrez écrire un file MDL et le dissortingbuer avec votre application avec les binarys Wizardby, et pendant l'installation, l'installation vérifiera si la version de la database est à jour et si ce n'est pas le cas, elle appliquera toutes les modifications nécessaires.

En interne, il gère une table SchemaInfo , qui SchemaInfo migrations (versions) appliquées à une instance particulière de la database, afin de pouvoir exécuter de manière fiable uniquement les requêtes requirejses.

Si vous maintenez vos modifications dans le contrôle de source (par exemple SVN), vous pouvez utiliser un file batch avec SQLCMD pour déployer uniquement les dernières modifications d'une twig SVN particulière.

Par exemple,

 rem Code Changes sqlcmd -U username -P password -S %1 -d DatabaseName -i "..\relativePath\dbo.ObjectName.sql"

Supposons que vous mainteniez une twig SVN spécifiquement pour le deployment. Vous devez valider votre code sur cette twig, puis exécuter un file batch qui déploiera les objects souhaités.

Les inconvénients incluent l'impossibilité de vérifier à la volée les changements liés aux tables (par exemple, si l'un de vos scripts SQL implique l'ajout d'une colonne, si vous essayez de relancer le script, il ne sera pas assez intelligent pour voir la colonne dans une course précédente). Pour atténuer cela, vous pouvez créer une application pour créer le file de commands pour vous et créer une logique pour interagir avec la database de destination, vérifier les modifications qui ont déjà été appliquées ou non et agir en conséquence.