Discussion :

[tibofo]

Bonjour,
Je viens de voir un comportement qui me semble étrange (SQL 2019).
J'ai fait une sauvegarde d'une base de données.
J'ai fait qq modifs.
Puis j'ai lancé une tâche - Restaurer - Base de données (même comportement avec Fichiers) :
Il m'a restauré ma sauvegarde sans broncher et m'écrasant ma base en place. (pas la moindre alerte que j'allais écraser tout)

Pour moi, tout va bien, c'était un jeu de test sans gravité. Mais je me demande pourquoi il ne m'a pas alerté. Je ne coche même pas l'option WITH REPLACE.

Sauriez-vous me dire pourquoi afin de ne pas reproduire ce cas chez des clients ?
Merci
Thibault

[Michel.Priori]

Bonjour,

Un langage n'est pas une interface graphique.
Lorsqu'on code une restauration, ça s'exécute.
Idem pour un drop database.

A ma connaissance il n'y a qu'une seule exception : ALTER DATABASE ... MODIFY FILE... si on choisi de changer le chemin d'accès aux fichiers.
Qui ne le fait que dans les métadata ; c'est à l'admin de fermer la base et de placer les fichiers là où ils seront attendus au redémarrage de celle-ci.
Create ou drop manipulant les fichiers de conséquence.

[SQLpro]

D’où l'intérêt non pas d'appuyer bêtement sur OK, mai de demander le script SQL, de l'analyser et de le lancer si conforme à vos attentes... Donc ne jamais cliquer sur la touche OK des interfaces de SSMS.

A +

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

D’où l'intérêt non pas d'appuyer bêtement sur OK, mai de demander le script SQL, de l'analyser et de le lancer si conforme à vos attentes... Donc ne jamais cliquer sur la touche OK des interfaces de SSMS.

Je suis d'accord mais la fonction RESTORE peut contenir beaucoup d'arguments et ça peut être difficile à interpréter.

Pour l'anecdote, lors d'un test technique écrit pour une job, j'avais eu comme question de présenter les options du RESTORE avec explication, évidemment sans accès à la doc en ligne...