none
Differenza tra due stringhe di connessione RRS feed

  • 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

    giovedì 16 febbraio 2012 17:18

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


    giovedì 16 febbraio 2012 20:12
  • 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
    lunedì 20 febbraio 2012 08:27

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


    giovedì 16 febbraio 2012 20:12
  • 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

    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
    lunedì 20 febbraio 2012 08:27
  • Grazie di nuovo Francesco. Mi hai fornito un bel chiarimento.

    Ciao, Grazie.


    mario formosa

    lunedì 20 febbraio 2012 10:36
  • Grazie di nuovo Francesco. Mi hai fornito un bel chiarimento.

    Ciao, Grazie.


    mario formosa


    Di niente, ciao! :)

    Francesco Milano // .NET & SQL Server Consultant // blog // twitter

    lunedì 20 febbraio 2012 10:56