Ovvero comprendere come sono fatte le connection string e perché.
Fra ieri e oggi, abbiamo perso circa 8 ore di lavoro 4 x 2 persone per correre dietro al problema in oggetto. Una classe Data Provider usata N volte nei nostri progetti, di punto in bianco ha cambiato modo di funzionare, producendo errori incomprensibili.
Antefatto: Sto testando una serie di classi per una applicazione usando una semplice applicazione di test, visto che ho 2 diversi database su cui faccio i test, ho inserito una stringa di connessione in una textbox precompilata, in modo che posso cambiarla al volo.
Data Source=NomeServer;Initial Catalog=NomeDatabase;Password=LaPassword;User ID=LUtente;
La password era nella forma qui sopra. Nei vari test che ho fatto, uno di essi utilizza una classe DataProvider in cui c’è un Dataset, contenente una DataTable, governata da un SqlDataAdapter, 4 SqlCommand, una SqlConnection. Queste classi sono quelle che usualmente utilizziamo per il CRUD di tutte le tabelle e hanno sempre funzionato correttamente. Ieri sera invece una operazione di tipo Fill (chiamata alla Fill del DataAdapter) AddRow, Update (chiamata alla Update del DataAdapter) dava un errore dicendo che l’utente non aveva diritto di eseguire il login a SQL Server.
Dopo 3 ore di debug passo passo e un paio di tentativi di taglio di vene per lungo, abbiamo scoperto che il DataAdapter, dopo la chiamata alla Fill eliminava la password dalla proprietà ConnectionString dell’oggetto SqlConnection in automatico. Siccome era una delle classi che usiamo quotidianamente in tutte le nostre applicazioni abbiamo finito per domandarci come fosse possibile che fino a ieri funzionasse tutto.
Abbiamo fatto un nuovo test debuggando una delle nostre applicazioni e verificato una delle nostre connection string applicative scoprendo con gioia di non essere del tutto pazzi, ma che il problema era determinato dal fatto che la connection string avrebbe dovuto essere così:
Data Source=NomeServer;Initial Catalog=NomeDatabase;Password=LaPassword;User ID=LUtente;Persist Security Info=true;
Pertanto, se per caso vi capitasse che un DataAdapter dopo la prima chiamata ad uno dei suoi command si mangi la password, il motivo è questo. La clausola Persist Security Info è fra quelle “sconsigliate” e in sua assenza, dopo una apertura della connection a SQL Server, la password viene eliminata. E’ una cosa mi dicono essere logica e viene fatta per questioni di sicurezza. Questo tipo di problema riesce a farti sentire un idiota, anche perché uno si chiede, ma come è possibile che non mi sia mai successo da quando lavoro con SQL Server (2003) e .Net.