Framework .Net et ADO.NET

Pour arriver au même résultat que la console d’administration, avec certes moins d’options, mais qui aura l’avantage de s’intégrer directement dans un progiciel, nous créons une application Windows Forms, avec Visual Studio 2008. Au final l’application exemple ressemblera à ceci : Voir Figure 6.

La partie code se décompose en 2 parties distinctes :

1. La création du script : Celui-ci reprend les indications de l’utilisateur final et se contente de concaténer une chaîne de caractères : Voir listing 1. 
2. L’exécution du script généré : Il passe par l’utilisation de 2 composants indispensables ADO.NET : 

• Une connexion au serveur et à la base de données représentée par l’objet SqlConnection. 
• Une commande SQL a exécutée sur cette connexion représentée par l’objet SqlCommand. 

Tout ceci encapsulé dans une méthode gérant les erreurs, nous ne sommes pas à l’abri d’un problème de réseau, d’un serveur SQL SERVER arrêté etc. Voir listing 2 Note : La connexion SqlConnection permet de lever des évènements lorsqu’un message arrive depuis SQL SERVER. Nous nous accrochons à cet évènement « InfoMessage » qui nous permet d’afficher notre barre de progression. Voir listing 3.

Cette méthode utilise ADO.NET et attaque directement le serveur SQL SERVER via des scripts SQL générés par notre application. Il nécessite donc de connaître le langage Transact-SQL nécessaire pour faire un sauvegarde. Mais il existe une autre méthode, qui permet encore de passer par .Net et développer une interface graphique propriétaire, mais sans toutefois connaître l’ensemble des commandes SQL à exécuter : SMO