Rollback SQL Server

Bonjour,

Ce matin, j'ai été un peu trop vite, et j'ai delete certaines données dans une base sql server 2k8.

Parait-il qu'un ROLLBACK peut recréer les données que j'ai effacé.

Mais d'autre utilisateurs bossent sur la base depuis ce matin, du coup je me demande si ce qu'ils ont fait ne sera(i?) pas effacé.

En gros, le rollback concerne-t-il uniquement les requetes de la connexion en cours ?

Merci pour votre aide..

Le rollback ne concerne que les requêtes dans la transaction en cours.

Si malheureusement tu n'as pas mis tes requêtes dans une transaction, tu ne pourra pas faire de rollback. Il doit être fait avant la fermeture de la transaction
En l'absence de transaction, une transaction est automatiquement créée pour chaque requete exécutée mais celle-ci est automatiquement fermée soit par un commit si tout va bien, soit par un rollback, s'il y a une erreur, mais dans les 2 cas toujours avant de rendre la main à l'utilisateur.

Le seul moyen de revenir en arrière serait de restaurer une sauvegarde de la base à la date de hier soir (ou de ce matin avant ton intervention). Bien entendu tout ce qui a été fait depuis serait perdu

Sinon, il ne te reste plus qu'à ressaisir les données effacées

---- Sevyc64 (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #

Salut, merci pour ta réponse.

En effet, j'ai trop espéré d'un sgbd M$ a 6000 ¤ : D

je vais essayer de restaurer via une sauvegarde d'hier dans une nouvelle bdd, de récup les données et de les recréer à la main.

Merci pour ton explication !

Quand tu fais une connerie sur la route et que tu cartonne ta voiture, quelque soit son prix tu n'espère pas non plus qu'elle ait une fonction pour revenir en arrière

---- Sevyc64 (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #

Certes, mais quand tu met des sous dans une tuture, t'espère qu'elle ai des airbag ou autre pour réduire les dégats. On parle de programmation là, quand on a la prétention de faire un produit de qualité.... Après je me trompe peut-être, mais au final, un bon mysql et on économise 6k pour un produit de même qualité.

Oui, peut-être mais même avec MySQL si tu fait la même manip, tu aura le même résultat.

Le problème dans le cas présent ne vient pas du produit mais de celui qui l'a utilisé.

Le produit n'a fait qu'exécuter les instructions qui, pour lui, étaient correctes, sinon tu aurais eu une erreur. Le produit, quel qui soit, ne peut pas savoir que, Toi, tu ne devais pas effacer ces données là.


---- Sevyc64 (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #

Me semble avoir vu qu'Oracle le faisait non ? Par un système d'écriture de données dans une espace en boucle, effaçant "réellement" certaines données qu'au bout d'un certain temps ?

Je ne me prononcerais pas sur Oracle que je ne connais pas, mais la plupart des SGBD performants fonctionnent de la sorte. Les modifications de la base ne sont pas écrites directement sur la base elle même, elles sont stockées dans un tampon, pour SQLServer, on appelle ça "Journal". Les modifications étant réellement inscrite dans la base lorsque les conditions le permettent. Ça peut-être quelques secondes, minutes, ou plusieurs heures après.

Cela n'empêche, que, même si les modifications ne sont pas faites directement sur la base, elles sont considérées comme faite par le moteur du SGBD, car pour ce moteur, la base de données, c'est la base physique + les journaux.

A ma connaissance, en SQLServer, il n'est pas possible de défaire les instructions dans un journal.
Et j'imagine que cela doit être la même chose sous Oracle.

De toute façon, au mieux si c'était possible, tu perdrais tout ce qui a été fait après la manip que tu veux annuler.

---- Sevyc64 (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #

Déjà on ne parle pas du SGBD mais des outils qui y sont associés.
Les outils Oracle ne créent tout simplement pas de Transaction implicite, donc si tu oublie de passer un ordre COMMIT il ne se passe rien et les locks posé sur la table reste jusqu'a un commit ou un rollback, autant dire qu'il m'est arrivé souvent de killer des users (pour rollbacker leurs transaction) qui etaient parti déjeuné sans faire de commit ou de rollback et bloquaient tous leurs collegues.
Le parti pris de SQL Server est d'ouvrir une transaction implicite qu'il termine par un commit ou un rollback pour eviter ce genre de situation.

Dans les 2 cas, un utilisateur averti peut soit activer (cas d'Oracle) soit désactivé (cas SQL Server Management Studio) ce qu'on appel vulgairement l'autocommit.
Pour les Outils tournant autour de SQL SERVER un petit SET IMPLICITE_TRANSACTION OFF et c'est réglé, tu peux bloquer tes collegues ad vitam eternam via tes requetes update/delete tant que tu n'aura pas ecrit et executer un commit tran ou rollback tran.

Quand au cas MySQL ... ne confondons pas les legos Technics(Oracle/SQL Server/Postgres si on veux regarder dans le gratuit) et les Duplo(MySQL) merci... Je ne dirais rien de plus sur MySQL en dehors du fait que ce "truc" est une parfaite hérésie, totalement minable, créateur d'ignominie sans nom.

(Pour info j'ai pris violament en grippe MySql suite a cette discussion : http://www.sqlfr.com/forum/sujet-COMMENT-FAIRE-COUNT-SANS-GROUP-BY-INTERMINABLE_1348349.aspx . Quand un moteur se veut relationnel et SQL tolérer des syntaxe abéhrante est tout bonnement inadmissible.)