Discussion :

[Gluups]

Bonjour tout le monde,

Il y a peu, après avoir réinstallé SQL Express 2014, j'ai installé la base NorthWind.
J'ai lancé le script deux ou trois fois, et je ne voyais rien apparaître.

C'est ensuite que je me suis rendu compte que j'étais supposé lire le début avant exécution : "Ce script ne crée pas de base de données. Sélectionnez la base dans laquelle vous voulez créer les tables et autres objets."

Aussi je viens d'avoir une surprise :


Sans trop savoir pourquoi, je me dis plus ou moins intuitivement que la table master de SQL Server n'est pas supposée connaître de clients, d'employés ni de commandes.

Qu'est-ce que je dois laisser, dedans ?

J'ose espérer que ça ne m'oblige pas à tout réinstaller ?

(C'est "amusant" : quand j'ai téléchargé la copie d'écran, l'aperçu a fait apparaître les noms de tables dans une très grosse police ; or, après publication je vois que c'est tout petit. Ah oui c'est parce que ça s'adapte à la largeur de la fenêtre dans laquelle ça s'affiche.)

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

Je te rassure, ça nous ait tous arrivé de créer accidentellement de quoi dans master !
Normalement, il ne devrait pas y avoir de tables visibles dans master.

Pour voir les objets que ton script a créé dans master, tu peux regarder les objets qui ont été créé à l'heure où tu as lancé ton script :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from sys.all_objects order by create_date desc

Cela dit, ces objets n'auront pas d'impact sur le bon déroulement de l'instance. Si tu n'es pas sûr de ton coup dans la suppression des objets, laisse ça là, surtout si c'est pas de la production.

[Gluups]

Ah bien vu, merci.
Du coup il ne me reste plus qu'à écrire un script pour détruire ce qui a été créé ce jour-là, tables, procédures stockées, enfin tout le bazar.
C'est mieux de ne pas trop tarder, comme ça en cas de loupé je n'ai presque rien de perdu, juste ce que j'ai restauré depuis l'installation.

Je me vois bien faire ça en C#, encore que PowerShell serait un bon candidat aussi semble-t-il.

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

Je me vois bien faire ça en C#, encore que PowerShell serait un bon candidat aussi semble-t-il.

Pourquoi ne pas faire ça simplement en T-Sql, quitte à travailler dans une bd ? Ça me semble le plus simple !
DROP TABLE dbo.nomTable
DROP PROCEDURE dbo.Proc...

[Gluups]

Pourquoi ne pas faire ça simplement en T-Sql, quitte à travailler dans une bd ? Ça me semble le plus simple !
DROP TABLE dbo.nomTable
DROP PROCEDURE dbo.Proc...

Effectivement c'est intéressant, ça reste plus dans le domaine. Il va falloir que je m'accroche un peu plus, par exemple.

(Il y a des histoires de mails d'alerte qui m'agacent un chouïa.)

[SQLpro]

Ah bien vu, merci.
Du coup il ne me reste plus qu'à écrire un script pour détruire ce qui a été créé ce jour-là, tables, procédures stockées, enfin tout le bazar.
C'est mieux de ne pas trop tarder, comme ça en cas de loupé je n'ai presque rien de perdu, juste ce que j'ai restauré depuis l'installation.

Je me vois bien faire ça en C#, encore que PowerShell serait un bon candidat aussi semble-t-il.

Il faut d'abord supprimer les contraintes FOREIGN KEY...

Le moyen le plus simple est d'utiliser du SQL !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
DECLARE @SQL NVARCHAR(max) = N'';
SELECT @SQL = @SQL + 'ALTER TABLE [' + TABLE_SCHEMA + '].[' + TABLE_NAME + '] DROP CONSTRAINT [' + CONSTRAINT_NAME + '];'
FROM   INFORMATION_SCHEMA.TABLE_CONSTRAINTS
WHERE  CONSTRAINT_TYPE = 'FOREIGN KEY'
EXEC (@SQL);
SET @SQL = N'';
SELECT @SQL = @SQL + 'DROP TABLE [' + TABLE_SCHEMA + '].[' + TABLE_NAME + '];'
FROM   INFORMATION_SCHEMA.TABLES
EXEC (@SQL);

Il faudra aussi faire cela pour les objets de code : Procédure, fonctions....

A +

[Gluups]

Il faudra aussi faire cela pour les objets de code : Procédure, fonctions....

En effet, j'avais bien repéré ça.
Sinon une dizaine de clics, puis appui sur suppression et envoi, ça devrait aller plus vite.

[Gluups]

Je dois avouer que pour quelqu'un qui voulait faire vite je charrie un peu ...

select * from INFORMATION_SCHEMA.TABLES

Bon il y e n a 17 :
master dbo VIEW Alphabetical list of products
master dbo VIEW Current Product List
master dbo VIEW Orders Qry
master dbo VIEW Products Above Average Price
master dbo VIEW Products by Category
master dbo VIEW Quarterly Orders
master dbo VIEW Invoices
master dbo VIEW Order Details Extended
master dbo VIEW Order Subtotals
master dbo VIEW Product Sales for 1997
master dbo VIEW Category Sales for 1997
master dbo VIEW Sales by Category
master dbo VIEW Sales Totals by Amount
master dbo VIEW Summary of Sales by Quarter
master dbo VIEW Summary of Sales by Year
master dbo VIEW spt_values
master dbo VIEW Customer and Suppliers by City

Vachement simple à taper, comme requête,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM [Alphabetical list of products]

Coup de pot il n'y a pas une table "Alphabetical list of products that were not commanded in the first quarter and are not sold out".

J'ai changé l'ordre des colonnes, parce que VIEW à la fin faisait de méchants zig-zags. Il y a un outil tableau, sur le forum, mais qui met toute la table dans la même cellule.

Maintenant, j'ai l'impression que j'ai intérêt à éplucher ça à la main, parce des tables doivent rester sur master, et ... logiquement elles doivent être dans la liste.

[SQLpro]

Je te rassure, ça nous ait tous arrivé de créer accidentellement de quoi dans master !
Normalement, il ne devrait pas y avoir de tables visibles dans master.

Pour voir les objets que ton script a créé dans master, tu peux regarder les objets qui ont été créé à l'heure où tu as lancé ton script :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from sys.all_objects order by create_date desc

Cela dit, ces objets n'auront pas d'impact sur le bon déroulement de l'instance. Si tu n'es pas sûr de ton coup dans la suppression des objets, laisse ça là, surtout si c'est pas de la production.

Non ! Pas all_objecxts qui cumule les entrées de master et des bases locales avec les tables système...

Toujours utiliser INFORMATION_SCHEMA.TABLES et INFORMATION_SCHEMA.ROUTINES

Qui indique les objets uitilisateurs seulement...

A +

[Gluups]

Non ! Pas all_objecxts qui cumule les entrées de master et des bases locales avec les tables système...

Toujours utiliser INFORMATION_SCHEMA.TABLES et INFORMATION_SCHEMA.ROUTINES

Qui indique les objets uitilisateurs seulement...

A +

Ah effectivement, c'est bien d'être précis, merci.
Dans ce cas-ci on arrivera au même résultat car au moment de tenter de créer la base NorthWind je n'ai rien modifié d'autre, mais ça, ça ne sera pas forcément vrai à chaque coup.