Cannot open user default database. Login failed. Login failed for user “UserName”. (Microsoft SQL Server, Error: 4064)
Ringrazio Benjamin Harrell per aver postato la soluzione a questo problema sul suo blog.
Quando si verifica questo errore? Quando in SQL Management Studio facciamo il Detach o Cancelliamo il Database che è stato assegnato al nostro utente come Database di Default.
Come potete vedere nella foto, gli utenti amministratori, in questo caso hanno MusicBox2005 come database di default. Io come amministratore della macchina locale appartengo a questo gruppo di utenti in SQL Server quando mi loggo con una Trusted Connection, se dopo essermi loggata, faccio il detach di MusicBox2005, ebbene il risultato è l’errore in testa a questo blog.
E voi direte, perché non hai messo il master come database di default?
Perché stavo lavorando su MusicBox2005 e in SQL Management Studio, è necessario riloggarsi ogni 3 secondi e lasciando il db Master, ogni volta che preparo una query oppure una Stored Procedure, se non mi ricordo di cambiare il DB connesso nella combobox in cima alla form della query, scrivo schifezze sul DB Master o comunque devo fare operazioni in più che mi fanno lavorare più lenta quindi viva il DB di Default. (Ditemi che non lo avete mai fatto e il naso vi crescerà di 20 centimetri!)
Nonostante sapessi bene cosa accadeva, oggi stavo ripulendo il mio Notebook-Muletto (muletto in termine Formula 1), da tutto ciò che era vecchio, compresi i vecchi database perché devo fare spazio per altre cose, ho fatto ciò che non dovevo, ho fatto il detach del db di default e ho provocato l’inferno…
Per fortuna c’è internet, trovata la soluzione, ringraziando l’autore, scrivo un appunto anche in italiano.
L’errore è fastidiosissimo e soprattutto blocca fisicamente e psicologicamente chi vi si trova davanti, vediamo come:
Mi sono connessa via trusted connection, sono sysadmin quindi posso fare ciò che voglio, inizio a fare il detach dei database, ma non ricordandomi di aver impostato il DB di Default, ne faccio il detach che viene eseguito senza problemi. Però appena cerco di fare il detach della vittima seguente, come d’incanto, non riesco più a fare nulla, appare questo errore, se tento di accedere alle proprietà del mio utente l’errore si scatena di nuovo, se tento di fare una query a mano si scatena di nuovo e non posso creare la query, qualunque cosa faccia, si ripresenta l’errore.
Non posso nemmeno riattaccare il famigerato database perché appare questo messaggio di errore, e nonostante il ruolo da SysAdmin, sono praticamente impossibilitata a fare qualsiasi cosa perché per fare qualunque operazione sugli utenti, i login, i database, le credenziali con il db sbagliato vengono passate a SQL Server che ridà sempre lo stesso errore.
Nessuno di noi che lavoriamo con SQL Server quotidianamente, si spiega il motivo per cui anche dopo SP2 (ho controllato) Microsoft non abbia provveduto ad una soluzione soft di questo problema, come ad esempio, prima di un detach controllare che il database non sia default database di uno o più utenti richiedendo all’utente di cambiare manualmente o indicare un db con cui sostituire il db di default per gli utenti a cui sarà eradicato.
La soluzione
Aprire SqlServer Management studio, alla comparsa della finestra di connessione indicare l’utente incriminato (o la trusted connection se è così che vi loggate con errore).
- Premere il tasto Options
- fare click sul Tab Connection Properties se non è già attivo.
- Scrivere Master al posto di nella dropdown Connect to Database
- Click su Connect
Magicamente siamo connessi senza più l’errore, ma non tutto funziona, infatti se provate ad aprire la cartella security per andare a modificare il database di default del vostro utente in modo da riavere il controllo, viene scatenato nuovamente il messaggio di errore, perché, come già detto vengono passate le credenziali dell’utente originali, non quelle che avete modificato 3 secondi fa nella finestra di connessione e stavolta non c’è una finestra di dialogo e la possibilità di cambiare il database.
Non c’è modo di uscire da questo giro vizioso all’interno di SQL Management Studio in modo diretto, per fortuna, almeno le Query si possono eseguire, pertanto, per cessare definitivamente le nostre sofferenze, apriamo una nuova query facendo attenzione ad usare il DB Master e non quello che non esiste più e digitiamo il seguente codice:
ALTER LOGIN loginid WITH DEFAULT_DATABASE = master
Ove loginid è il nome del nostro login, che in caso di trusted connection sarà
NomeDominio\Nomeutente oppure nel caso di un pc non in rete NomePc\Nomeutente.
Eseguita questa Query, tutto tornerà normale, e probabilmente eviteremo di mettere
il database di default al nostro utente amministrativo, almeno per una settimana
o due, poi lo faremo di nuovo e ci troveremo di nuovo in questa situazione.
Ma almeno, la prossima volta ce l’ho sul blog 😉