Principale utente con più risposte
Differenza tra due stringhe di connessione

Domanda
-
Buona sera, chiedo il vostro aiuto per avere spiegazioni circa la differenza tra due stringhe di connessione.
Stringa 1:
"Data Source=PCSEVEN;Initial Catalog=dbdiprova;Integrated Security=True"
Stringa 2:
"Data Source=PCSEVEN;AttachDbFilename=C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\DBdiProva.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True"
Passando la stringa 2 al costruttore di di una classe SqlConnection in un'applicazione riesco ad effettuare la connessione. Stessa Cosa se passo la Stringa 1.
Però se prima ho passato la stringa 2 poi non riesco più a connettermi con la stringa 1 e ricevo questo messaggio :
Cannot open user default database. Login failed.
Login failed for user 'PcSeven\Mario'.Se non Chiedo troppo potete dirmi che succede ?
Grazie 1000 !
mario formosa
Risposte
-
Ciao Mario,
la differenza tra le due connection string è la seguente: la prima è una connessione al db "dbdiprova" dell'istanza di default di SQL Server installata sul pc; la seconda connection string invece, sfruttando una caratteristica (User Instances) introdotta in SQL Server 2005 Express ma ormai deprecata a partire da SQL Server 2008 - sì esatto, neanche il tempo di ambientarsi :-) -, avvia un processo figlio del processo principale di SQL Server impersonando l'utente chiamante e successivamente viene fatto l'attach del db specificato nel path di AttachDbFileName. Questa istanza "locale" viene chiusa dopo una decina di minuti di inattività.
Trovi un ottimo articolo sulle User Instances qui: http://msdn.microsoft.com/en-us/library/bb264564(v=sql.90).aspx
Tieni conto che in SQL Server 2012 è stato introdotto LocalDb che prende a tutti gli effetti il posto delle User Instances.
Quindi, nel tuo caso, stai connettendoti all'istanza principale con la prima connection string (ci sarà quindi un db di nome "dbdiprova" visibile ad esempio da Management Studio) mentre con la seconda stai creando un'instanza locale e isolata "costola" della principale in un ambito di sicurezza relativo all'account che apre la connessione.
Non capisco però cosa intendi con "non riesco più a connettermi con la stringa 1": per quale motivo hai bisogno di due stringhe di connessione di questo tipo? E soprattutto, le connessioni al db come vengono gestite dall'applicativo (intendo aperture, chiusure, ecc)?
Ciao!
Francesco Milano // .NET & SQL Server Consultant // blog // twitter
- Modificato Francesco Milano giovedì 16 febbraio 2012 20:12
- Contrassegnato come risposta Mario Formosa venerdì 17 febbraio 2012 16:08
-
Ti ringrazio Francesco per la bellissima risposta che mi hai dato.
Mi spiego meglio.
La mia domanda l'ho posta perchè in un thread del forum VB circa l'utilizzo di un oggetto SqlConnection in un esempio di codice, un altro utente usava la stringa 2 come stringa di connessione, che a me risultava come una novità. Poi quando in questo codice di esempio io alternavo l'utilizzo delle due stringhe mi sono accorto del problema.
In pratica se avvio il codice di esempio con la stringa 1 la connessione avviene. Stessa cosa se avvio con la stringa 2. Però se dopo aver avviato con una delle due stringhe, tento di riavviare con l'altra, si verifica l'eccezione. E' chiaro che non uso contemporaneamente le due stringhe. O l'una o l'altra.
Per maggiore chiarezza, se ti va, puoi vedere il thread suddetto.
Ciao e Grazie ancora.
mario formosa
Ciao Mario,
ho dato un'occhiata al thread che mi hai indicato. Tieni conto che di default ADO.NET gestisce le connessioni a SQL Server tramite un pool, infatti quando chiudi una SQLConnection verso il db non stai a tutti gli effetti chiudendo del tutto il canale con il db, ma semplicemente liberi un "posto" nel pool di connessioni. Le connessioni nel pool, se non usate, dopo un tempo di timeout (configurabile) vengono chiuse definitivamente. Se all'apertura di una connection verso il db dal tuo applicativo viene trovata una connessione latente nel pool e sono soddisfatte determinate condizioni viene utilizzata quella e non hai l'overhead dell'apertura di una nuova connessione ex-novo.
Maggiori informazioni qui: http://msdn.microsoft.com/it-it/library/8xx3tyca.aspx
Detto questo, se puoi evitare di basare i nuovi applicativi sulle user-instances, evita. Piuttosto dai un'occhiata a SQL Express LocalDB, che ormai manca poco al suo rilascio ufficiale :)
Francesco Milano // .NET & SQL Server Consultant // blog // twitter
- Contrassegnato come risposta Mario Formosa lunedì 20 febbraio 2012 10:35
Tutte le risposte
-
Ciao Mario,
la differenza tra le due connection string è la seguente: la prima è una connessione al db "dbdiprova" dell'istanza di default di SQL Server installata sul pc; la seconda connection string invece, sfruttando una caratteristica (User Instances) introdotta in SQL Server 2005 Express ma ormai deprecata a partire da SQL Server 2008 - sì esatto, neanche il tempo di ambientarsi :-) -, avvia un processo figlio del processo principale di SQL Server impersonando l'utente chiamante e successivamente viene fatto l'attach del db specificato nel path di AttachDbFileName. Questa istanza "locale" viene chiusa dopo una decina di minuti di inattività.
Trovi un ottimo articolo sulle User Instances qui: http://msdn.microsoft.com/en-us/library/bb264564(v=sql.90).aspx
Tieni conto che in SQL Server 2012 è stato introdotto LocalDb che prende a tutti gli effetti il posto delle User Instances.
Quindi, nel tuo caso, stai connettendoti all'istanza principale con la prima connection string (ci sarà quindi un db di nome "dbdiprova" visibile ad esempio da Management Studio) mentre con la seconda stai creando un'instanza locale e isolata "costola" della principale in un ambito di sicurezza relativo all'account che apre la connessione.
Non capisco però cosa intendi con "non riesco più a connettermi con la stringa 1": per quale motivo hai bisogno di due stringhe di connessione di questo tipo? E soprattutto, le connessioni al db come vengono gestite dall'applicativo (intendo aperture, chiusure, ecc)?
Ciao!
Francesco Milano // .NET & SQL Server Consultant // blog // twitter
- Modificato Francesco Milano giovedì 16 febbraio 2012 20:12
- Contrassegnato come risposta Mario Formosa venerdì 17 febbraio 2012 16:08
-
Ti ringrazio Francesco per la bellissima risposta che mi hai dato.
Mi spiego meglio.
La mia domanda l'ho posta perchè in un thread del forum VB circa l'utilizzo di un oggetto SqlConnection in un esempio di codice, un altro utente usava la stringa 2 come stringa di connessione, che a me risultava come una novità. Poi quando in questo codice di esempio io alternavo l'utilizzo delle due stringhe mi sono accorto del problema.
In pratica se avvio il codice di esempio con la stringa 1 la connessione avviene. Stessa cosa se avvio con la stringa 2. Però se dopo aver avviato con una delle due stringhe, tento di riavviare con l'altra, si verifica l'eccezione. E' chiaro che non uso contemporaneamente le due stringhe. O l'una o l'altra.
Per maggiore chiarezza, se ti va, puoi vedere il thread suddetto.
Ciao e Grazie ancora.
mario formosa
-
Ti ringrazio Francesco per la bellissima risposta che mi hai dato.
Mi spiego meglio.
La mia domanda l'ho posta perchè in un thread del forum VB circa l'utilizzo di un oggetto SqlConnection in un esempio di codice, un altro utente usava la stringa 2 come stringa di connessione, che a me risultava come una novità. Poi quando in questo codice di esempio io alternavo l'utilizzo delle due stringhe mi sono accorto del problema.
In pratica se avvio il codice di esempio con la stringa 1 la connessione avviene. Stessa cosa se avvio con la stringa 2. Però se dopo aver avviato con una delle due stringhe, tento di riavviare con l'altra, si verifica l'eccezione. E' chiaro che non uso contemporaneamente le due stringhe. O l'una o l'altra.
Per maggiore chiarezza, se ti va, puoi vedere il thread suddetto.
Ciao e Grazie ancora.
mario formosa
Ciao Mario,
ho dato un'occhiata al thread che mi hai indicato. Tieni conto che di default ADO.NET gestisce le connessioni a SQL Server tramite un pool, infatti quando chiudi una SQLConnection verso il db non stai a tutti gli effetti chiudendo del tutto il canale con il db, ma semplicemente liberi un "posto" nel pool di connessioni. Le connessioni nel pool, se non usate, dopo un tempo di timeout (configurabile) vengono chiuse definitivamente. Se all'apertura di una connection verso il db dal tuo applicativo viene trovata una connessione latente nel pool e sono soddisfatte determinate condizioni viene utilizzata quella e non hai l'overhead dell'apertura di una nuova connessione ex-novo.
Maggiori informazioni qui: http://msdn.microsoft.com/it-it/library/8xx3tyca.aspx
Detto questo, se puoi evitare di basare i nuovi applicativi sulle user-instances, evita. Piuttosto dai un'occhiata a SQL Express LocalDB, che ormai manca poco al suo rilascio ufficiale :)
Francesco Milano // .NET & SQL Server Consultant // blog // twitter
- Contrassegnato come risposta Mario Formosa lunedì 20 febbraio 2012 10:35
-