Comment importer les scripts SQL enregistres dans la base de donnees?

Réponse:

Il existe deux façons d’enregistrer les données, prises en charge par Recovery Toolbox for SQL Server:

Vous pouvez enregistrer les scripts SQL sur le disque dur, ils vont créer des objets de base de donnée, des tables, par exemple, et insérer les données dans ces tables.
Vous pouvez également lancer les scripts dans les bases de données, définies par l’utilisateur, ces scripts sont écrits en langue SQL.

Notez, s’il vous plaît, que les scripts SQL peuvent être différents, bien qu’ils se basent sur les mêmes fichiers de la base de données. Cela peut avoir lieu à cause des particularités de la syntaxe dans les requêtes, qui sont exécutées pour la connexion directe au serveur au moyen d’ADO ainsi que dans les requêtes SQL, effectuées dans l’environnement de l’Analyseur de requêtes qui est fourni avec MS SQL Server (l’emploi de “:”, de la commande Aller, etc.). La première méthode est plus sûre, tandis que la deuxième méthode est plus pratique.

1. Conversion des donnees en scripts et la sauvegarde sur le disque.

1.1. Mise en correspondance des donnees enregistrees.

Si vous avez choisi d’enregistrer les données sur le disque, Recovery Toolbox for SQL Server va créer un sous-répertoire, qui va comprendre le nom du fichier source MDF, ce sous-répertoire est créé dans le répertoire défini par l'utilisateur et tous les scripts y seront placés. Tous les scripts sont nommés selon la règle, les noms comprennent un mot et un chiffre. Le mot indique le rôle du script, le chiffre indique son numéro. Il y a beaucoup de types de scripts, par exemple:

Types*.sql – les scripts vont créer des types de données, définies par l'utilisateur
Tables*.sql – les scripts vont créer des tables
Indexes*.sql – les scripts vont créer des clés primaires et des index
ForeignKeys*.sql – les scripts vont créer des clés étrangères.
Procedure*.sql – les scripts vont créer des procédures enregistrées.
Function*.sql – les scripts vont créer des fonctions, définies par l'utilisateur.
View*.sql – les scripts vont créer des affichages.
Triggers*.sql – les scripts vont créer des déclencheurs.
Data*.sql – les scripts vont insérer les données dans les tables.

Le numéro d'ordre de script ne contient aucune donnée utile, il ne désigne pas l’ordre d’exécution du script ni aucune autre information. Ces numéros sont utilisés uniquement pour diviser les données et les enregistrer dans de nombreux petits documents au lieu d’un grand fichier. Les utilisateurs peuvent définir la taille maximum du fichier avec le script SQL. De plus les utilisateurs devraient prendre note de la numération des fichiers de données. Ce qui doit être noté, c’est que chaque fichier du Type de données peut contenir des données pour une table seulement. Les fichiers avec les numéros d’ordre contiennent toutes les données pour chaque table.

Remarque: S’il manque des numéros pour certains fichiers, cela veut dire que certaines tables ne contiennent aucune donnée.

1.2. Ordre d’execution des scripts

Vous pouvez voir sur cette image l’ordre recommandé d’exécution des scripts:

L’ordre d’exécution des scripts dépend des restrictions existantes pour les données existantes et de la structure de la table. Veuillez prêter une attention particulière aux facteurs suivants:

Veuillez indiquer la clé primaire correspondante si vous aimeriez créer une clé secondaire. Pour cette raison, ces opérations sont enregistrées dans des fichiers différents, qui doivent être lancés dans cet ordre.
Avant de créer des index et des clés secondaires, le programme remplit les tables. C’est obligatoire, puisque la vérification de l'intégrité référentielle est effectuée lorsque la table avec les clés secondaires définies est remplie. Quand les tables avec les clés secondaires sont remplies avant les tables avec les clés primaires correspondantes, il s’agit d’une erreur. De plus, cette méthode présente une autre particularité. Si les données récupérées sont en conflit avec la clé primaire, les index uniques, etc., dans ce cas, la table sera remplie avec des données quand même, mais les restrictions ne seront pas créées (index, clé primaire, etc.). Si les utilisateurs exigent un autre comportement, ils peuvent sélectionner l’ordre d’exécution des scripts eux-mêmes.
La création des objets de procédures, fonctions, affichages et déclencheurs dans la base de données présente certaines difficultés, parce que ces objets peuvent avoir des dépendances sophistiquées et ambigües. Les procédures peuvent se rapporter à d’autres procédures, les affichages peuvent se rapporter aux fonctions, les déclencheurs peuvent se rapporter à tous les objets. C’est pourquoi le programme ne peut pas aider à résoudre cet embrouillement. Les utilisateurs devraient trouver toutes les dépendances à la main et lancer les scripts SQL dans l’ordre nécessaire. Une autre possibilité est celle d’exécuter tous les scripts dans ce groupe plusieurs fois, jusqu’à ce que le message d’erreur ne disparaisse.

1.3. Fichier Install.bat

Le fichier Install.bat est créé pour assurer l’exécution automatisée à tous les scripts. Ce fichier exécute tous les scripts, qui ont été précédemment sauvegardés par l’outil. L’ordre d’exécution des scripts sera le même, comme lors de l’application à la base de données. Ce fichier de lot exige l’installation de l’utilitaire isqlw, c’est la partie de la partie client de MS SQL Server. Veuillez spécifier les paramètres Nom du Serveur, Nom de la base de données, Nom d’utilisateur et Mot de passe pour le fichier install.bat dans la ligne de commande. Par exemple: install.bat SQLServer SQLBasededonnées SQLUtilisateur SQLMotdepassed’utilisateur

Attention:

Les paramètres doivent être séparés par des espaces. Si le paramètre lui-même contient un espace, vous devriez le mettre entre guillemets.
L’ordre des paramètres ne peut pas être modifié.

Si le fichier install.bat est exécuté sans paramètres, vous verrez un court guide, expliquant comment lancer ce fichier.

Vers le haut