On s'est trouvé dans la mouise aujourd'hui au boulot sur une petite base MSSQL Server Express utilisée pour stocker deux ou trois bricoles et surtout beaucoup de logs. Après plusieurs années de bons et loyaux services, elle est finalement arrivée à saturation, soit aux 4096Mo d'espace disque occupé, ce qui est la limite imposée par Microsoft et au-delà de laquelle il faudrait acheter une version plus élaborée. Mais voilà, acheter une licence pour des logs, c'est un peu limite. Du coup, on a un peu cherché et remarqué que le logiciel qui loguait avait des procédures stockées permettant de réduire la quantité de donnée stockée (taille de l'historique).

Problème: on n'avait pas accès à la base de données, le serveur ayant été monté par un membre de l'équipe qui est parti il y a un moment. Du coup, pas de mot de passe pour le compte "sa" qui symbolise le super admin de MSSQL. On a un peu cherché, et finalement, on est tombés sur deux traces sérieuses que je poste ici et qui nous ont aidé à résoudre le problème en ligne de commande depuis le serveur-même:

• http://www.wikihow.com/Reset-SA-Password-in-Sql-Server : comment réinitialiser le mot de passe d'un utilisateur (exemple: SA) en ligne de commande depuis le serveur. Ne pas oublier d'ouvrir l'invite de commande en admin. La méthode 1 a été suffisante
• http://blog.sqlauthority.com/2008/12/24/sql-server-disable-and-enable-user-sa/ : comment réactiver un compte utilisateur désactivé. Le compte SA était désactivé donc impossible de se connecter dessus
• http://rahul-oncall.blogspot.ch/2012/02/enabled-sa-account-on-sql-express-when.html : comment autoriser la connexion à MSSQL Server aux utilisateurs Windows mais aussi aux utilisateurs MSSQL (comme SA, en l'occurrence)

Avec ça, on a pu reprendre le contrôle de l'instance et activer la procédure stockée de nettoyage proposée par le fabriquant du soft. Et tout est bien qui finit bien :-)

Un tutoriel sur la manière de désactiver l'auto commit sur les bases MSSQL (qui est activé par défaut).