none
Connessione Sql Server 2008 R2 Express tra 3 pc RRS feed

  • Domanda

  • Salve a tutti. La mia domanda è la seguente. Ho creato un programma scritto con VBasic 2010 Express, che attraverso Linq to Sql gestisce un database Sql Server 2008 R2 Express. Il programma l'avevo scritto stand-alone, ma ora ho la necessità di farlo girare su 3 pc, condividendo quindi il database affinché qualunque dei 3 pc possa aggiornare in tempo reale le varie tabelle. Ho 2 pc con Windows 7 e uno con Xp Home. Ho installato Sql Server su tutti e 3 i pc, e ho attuato tutte le procedure per attivare il protocollo TC/IP. Ho messo la porta statica 1433 e disattivato tutte le porte dinamiche; ho creato le eccezioni sui vari firewall di windows per abilitare in entrata la porta 1433, dopodichè ho effettuato prove di connessione con il comando da prompt: Telnet localhost 1433, e tutti e 3 i pc si connettono. Inoltre, ho provato a connettermi tra i 3 pc, con il comando: Telnet 192.168.1.x 1433, e tutti e 3 i pc si vedono tra loro senza problemi. A questo punto però ho bisogno di chiedervi come gestire da codice Vbasic la connessione. Cioè, per far funzionare il programma, devo installare con clickonce il programma su tutti e 3 i pc, e poi automaticamente il database viene condiviso? Cosa devo scrivere a livello di codice affinché i 3 pc si vedano in modo tale che, quando uno dei 3 utenti lavora sulle tabelle del database, qualsiasi append, update, etc, sia visibile a tutti e 3? Grazie in anticipo e un saluto a tutti.   Maurizio
    venerdì 20 aprile 2012 17:09

Risposte

  • salve,

    Ciao. In effetti avevo un pò di eccessiva confusione sull'argomento. Ora mi sembra tutto più chiaro e forse anche semplice. Cambiando la stringa di connessione 'DataSource' dalle impostazioni del sorgente, che attualmente è: DataSource=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\LTSQUITMG.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True con un'altra che punta al server, non dovrei aver problemi. Ti chiedo solo un consiglio, se puoi darmelo. Nel sito connection string.com ne ho trovate parecchie, ma non so bene quale usare. Tu cosa useresti? Ho inoltre letto che occorre autenticare Sql Server con autenticazione mista, e non solo di Windows, con relativa password. E' vero o posso farne a meno? Grazie e ciao


    qui "abbiamo un problema", non irrisolvibile, ma un problema c'e'... :)

    la tua attuale stringa di connessione prevede l'utilizzo di una User Instance, che come gia' ben sai, non permette connessioni remote da altri computer... quindi tutta la tua strategia, su "tutti i computer" deve cambiare per utilizzare non gia' la User Instance bensi' l'istanza "tradizionale" di SQL Server\SQLExpress; cio' ti consentira' sia connessioni locali che connessioni remote... come gia' Renarig ha detto, questo non e' di per se' un grosso problema, anche per il deploy, che come gia' avete affrontato, richiede "solo" che l'istanza di SQL Server\SQLExpress venga installata su 1 sola macchina, e che tutte le macchine "puntino" a quell'istanza... dovrai quindi anche rimuovere la proprieta' AttachDbFileName in quanto sara' buona prassi che tu registri i tuoi database al momento dell'installazione dell'istanza stessa... anche il deploy tramite ClickOnce putroppo ti verra' meno, ma potrai ad esempio benissimo passare a Wix, come anche a InnoSetup o altro strumento di generazioni di pacchetti di installazione "tradizionali", o anche l'installer "nativo" delle versioni "professionali" di Visual Studio...

    se utilizzi una versione Express di Visual Studio, abbandonare le User Instances ti comportera' anche l'impossibilita' di utilizzare i designers integrati di Visual Studio, che possono solo connettersi a "database SQL Server" (e quindi utilizzando solo la funzionalita' delle User Instances), ma ovviamente nulla vieta che tu utilizzi solo "puro codice" al loro posto...

    per quanto riguarda l'installazione dell'applicazione, il tutto risulta niente di particolarmente difficile, mentre diverso e' il caso dell'installazione, ad esempio, di SQLExpress... anche questo puo' in un qualche modo essere integrato nei pacchetti, anche se personalmente preferisco di gran lunga fare si che venga utilizzato il package "tradizionale" di SQLExpress, senza chiamate in shell e senza utilizzare i moduli di merge... il setup di SQLExpress e' relativamente semplice da utilizzare e non necessita' di particolari indicazioni se non per quanto eventualmente riguarda la necessita', spesso richiesta in ambiti WorkGroup (senza dominio), di abilitare anche l'autenticazione Mista (quindi permettendo sia autenticazioni WinNT [integrated security=true] che tramite login SQL Server tradizionali) e forse la collation di default dell'istanza (laddove necessario)...

    detto cio', dovrai anche predisporre, a livello applicativo, di poter specificare il server (l'istanza SQL Server\SQLExpress) che dovra' essere utilizzata tramite apposito dialogo, in modo da poter cosi' calibrare la connection string specifica per ogni singola macchina... come ben sai, diventa cosi' "difficile" trovare un posto sul file system dove ospitare il file di configurazione che mantenga questa informazione di connessione, "posto" accessibile in lettura/scrittura per tutti gli utenti di ogni singola macchina (laddove richiesto), mentre ovviamente in caso di assenza di questa esigenza generale il posizionamento in %appdata% va benissimo...

    per quanto riguarda la tipologia di autenticazione, Renarig ti ha correttamente indicato che l'autenticazione integrata WinNT sarebbe da preferire, ma questo spesso diventa un problema in assenza di un dominio (quindi in un WorkGroup)... spesso si utilizza un sistema di "inganno", generando su tutte le macchine coinvolte "tutte le login" del workgroup, quindi utilizzando un workaround di "impersonificazione"...  sulla macchina A saranno presenti le login di A\MauriVbe, A\Renarig, A\Andrea, mentre la macchina B avra' disponibili le login B\MauriVbe, B\Renarig, B\Andrea eccetera... quando B\Andrea tentera' di connettersi al server A, gli passera' la propria id di B\Andrea, e molto spesso (ma non sempre, attenzione), lo stack di rete riesce a mascherare B\Andrea in A\Andrea, quindi consentendo anche l'autenticazione all'istanza SQL Server (sempre che sull'istanza SQL Server siano state "registrate" le login locali A\MauriVbe, A\Renarig, A\Andrea o il loro gruppo WinNT di appartenenza)... il caveat e' ovviamente che non esiste un domain controller che gestisca veramente la cosa, ma il tutto "sta in piedi per quasi fortuna"... non e' garantito che prossime versioni del sistema operativo continuino a supportare questo workaround... spesso quindi, in ambiente WorkGroup si decade sull'autenticazione standard SQL Server... la tua gestionalita' potrebbe pero' ovviamente prevedere entrambe le funzionalita'...

    tornando alla "migrazione dalle User Instance", Roger indica abbastanza "superficialmente" in http://technet.microsoft.com/en-us/library/bb264564(v=sql.90).aspx#sqlexpuser_topic12 la prassi da seguire, ma ricorda che in ambiente SQL Server dovresti gestire tutta la "problematica" della sicurezza in maniera corretta, senza il "beneficio" dell'accesso garantito agli oggetti che ottenevi di default nell'altro ambiente, quindi, nuovamente, la parte di autenticazione (le login), la parte di accesso ai database (i database user) e la parte di accesso ai singoli oggetti table/viste/procedures...  nulla di insormontabile, ma tienilo presente, ricordandoti anche di referenziare gli oggetti (viste, tabelle, etc) sempre utilizzando il nome completo (schema.oggetto) in modo da non incorrere in subdole problematiche di incertezza come anche di non subire penalizzazioni prestazionali relative alla necessita' da parte del query optimizer di identificare "quale" tabella/vista/.. tu stia in effetti referenziano, problematica che a tutti gli effetti si risolve a runtime con l'ulteriore penalizzazione dell'impossibilita' di riutilizzare i piani di esecuzione gia' compilati...

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    sabato 21 aprile 2012 23:31
    Moderatore

Tutte le risposte

  • Non ho capito bene il problema...non puoi installare SQL Server solo su un server ed eseguire la connessione dal software che viene eseguito indipendentemente su ogni pc? Certo a seconda da come è strutturato il programma potresti aver bisogno di inserire ulteriori controlli per gestire la concorrenza, ma così il database è già centralizzato.
    venerdì 20 aprile 2012 18:27
    Moderatore
  • Non ho capito bene il problema...non puoi installare SQL Server solo su un server ed eseguire la connessione dal software che viene eseguito indipendentemente su ogni pc? Certo a seconda da come è strutturato il programma potresti aver bisogno di inserire ulteriori controlli per gestire la concorrenza, ma così il database è già centralizzato.

    Ciao Fabrizio. Ti ringrazio per avermi risposto. Il fatto è che ho letto decine di thread sull'argomento, e forse mi sono confuso le idee, e magari la soluzione è più semplice di ciò che credo. Ti scrivo altri dati per chiarire meglio il concetto. Nell'ufficio non ho un server dedicato, e il programma deve girare e quindi essere disponibile su tutti e 3 i pc. Ho letto da qualche parte che basterebbe centralizzare il database su un server su cui NON è installato il programma, ma per me non è possibile. Quindi, se installo il programma su tutti e 3 i pc attravserso clickonce, pubblico il programma che contiene, oltre a tutti i files .vb anche i files .mdf e .ldf. Ovviamente, lavorando sul programma il database viene modificato, e ciò che è modificato su un pc, deve essere modificato nello stesso istante anche sugli altri 2 pc. Scrivendo una stringa di connessione corretta, è possibile ottenere ciò, o devo agire in altro modo? Ciao e grazie.

    venerdì 20 aprile 2012 19:41
  • Se ho capito bene il tuo intento è di creare un'applicazione che legga e scriva dati verso SQL Server, ed hai la necessità che ogni utente che utilizza il tuo programma abbia i dati aggiornati da tutti gli altri utenti.

    La cosa migliore secondo me è utilizzare un solo SQL Server (che può essere installato anche su un pc che esegue la tua applicazione, non vedo il problema), poi la tua applicazione (installata su ogni computer) eseguirà una connessione separata al database, passando direttamente dalla rete. L'unico inconveniente è che dovresti lasciare il computer che ospita il database sempre acceso, altrimenti dovresti spostare il database all'esterno http://msdn.microsoft.com/it-it/library/ms175483.aspx o implementare un terminal server esterno (con SQL e l'applicazione installata) a cui ogni utente esegue una connessione in desktop remoto.

    L'idea dei 3 database separati a mio parere è assolutamente da non fare, questo perchè aggiungi un livello di complessità eccessivo ad una attività tutto sommato semplice. Premetto che non conosco molto clickonce ma non credo che possa fare una cosa del genere e anche se fosse possibile sarebbe una forzatura che potrebbe portare anche a perdite di dati (dovrebbe avere un algoritmo di gestione dei conflitti). Al massimo potresti implementare una replica tra le diverse installazioni di SQL Server, ma poi c'è tutta una problematica dovuta alla sincronizzazione che non ti porterebbe comunque a visualizzare dati aggiornati in tempo reale su tutti i pc.


    venerdì 20 aprile 2012 20:22
    Moderatore
  • Se ho capito bene il tuo intento è di creare un'applicazione che legga e scriva dati verso SQL Server, ed hai la necessità che ogni utente che utilizza il tuo programma abbia i dati aggiornati da tutti gli altri utenti.

    La cosa migliore secondo me è utilizzare un solo SQL Server (che può essere installato anche su un pc che esegue la tua applicazione, non vedo il problema), poi la tua applicazione (installata su ogni computer) eseguirà una connessione separata al database, passando direttamente dalla rete. L'unico inconveniente è che dovresti lasciare il computer che ospita il database sempre acceso, altrimenti dovresti spostare il database all'esterno: http://msdn.microsoft.com/it-it/library/ms175483.aspx

    L'idea dei 3 database separati a mio parere è assolutamente da non fare, questo perchè aggiungi un livello di complessità eccessivo ad una attività tutto sommato semplice. Premetto che non conosco molto clickonce ma non credo che possa fare una cosa del genere e anche se fosse possibile sarebbe una forzatura che potrebbe portare anche a perdite di dati (dovrebbe avere un algoritmo di gestione dei conflitti). Al massimo potresti implementare una replica tra le diverse installazioni di SQL Server, ma poi c'è tutta una problematica dovuta alla sincronizzazione che non ti porterebbe comunque a visualizzare dati aggiornati in tempo reale su tutti i pc.

    Quindi, se ho capito bene, in uno qualsiasi dei 3 pc installo il programma diciamo 'completo', con il riferimento diretto al database attraverso la connectionstring creata in automatico dall'applicazione quando ho generato il database, mentre gli altri 2 applicativi devono essere orfani di questo collegamento diretto, e puntare al solo database esistente attraverso una stringa di connessione ad hoc, dove viene scritto il riferimento al pc 'server' mediante l'indirizzo ip 192.168.1.x. E' corretto? Se è così, sapresti darmi un esempio di stringa di connessione corretta? Grazie ancora
    venerdì 20 aprile 2012 20:36
  • 
    

    Mi sa che hai le idee confuse ( lo dico in senso buono )

    NON ti occorre installare SQLServer sui 3 PC e fare in modo che i 3 DB vengano "Condivisi"

    Bensi Devi:

    Installare SQLSeever SOLO su 1 PC qualunque della rete  ( chiamiamolo PC1 )
    (Non deve necessariamente essere un server ,  è minimalmente sufficiente che sia in rete )

    Poi vai su un altro PC della rete ( chiamiamolo PC2 ) con la tua applicazione, stand-alone
    da questa  "Estirpi" il DB  e modifichi la stringa di connessione in modo che punti
    sul DB che si trova in  PC1

    Se hai fatto la applicazione per bene dovresti poter modificare solamente in un punto
    la stringa  altromenti ci vorra un po di pazienza

    Dovrai occuparti di superare il Firewall di PC1

    Fatto questo puoi installare la applicazione cosi come la hai modificata in PC2 su tutti
    i PC che vuoi
    ___ POTRAI INSTALLARLA ANCHE SU PC1
    Tutte le applicazioni andranno a cercare e modificare i dati sul DB di PC1  pertanto
    ogni modifica fatta da chiunque sara condivisa con tutti

    Inutile dirti che PC1 DEVE essere acceso per far funzionare le applicazioni
    sugli altri PC

    Nel gergo  PC1 si chiama Server
    Gli altri PC si chiamano Client

    Spero di essere stato utile

    venerdì 20 aprile 2012 20:38
  • Scusami Fabrizio,   Ho appena risposto ma non me ero accorto che anche tu qualche minuto prima

    avevi detto sostanzialmente le stesse cose.

    Non volevo superarti

    venerdì 20 aprile 2012 20:43
  • Scusami Fabrizio,   Ho appena risposto ma non me ero accorto che anche tu qualche minuto prima

    avevi detto sostanzialmente le stesse cose.

    Non volevo superarti

    Nessun problema, ci mancherebbe.
    venerdì 20 aprile 2012 21:43
    Moderatore
  • 
    

    Mi sa che hai le idee confuse ( lo dico in senso buono )

    NON ti occorre installare SQLServer sui 3 PC e fare in modo che i 3 DB vengano "Condivisi"

    Bensi Devi:

    Installare SQLSeever SOLO su 1 PC qualunque della rete  ( chiamiamolo PC1 )
    (Non deve necessariamente essere un server ,  è minimalmente sufficiente che sia in rete )

    Poi vai su un altro PC della rete ( chiamiamolo PC2 ) con la tua applicazione, stand-alone
    da questa  "Estirpi" il DB  e modifichi la stringa di connessione in modo che punti
    sul DB che si trova in  PC1

    Se hai fatto la applicazione per bene dovresti poter modificare solamente in un punto
    la stringa  altromenti ci vorra un po di pazienza

    Dovrai occuparti di superare il Firewall di PC1

    Fatto questo puoi installare la applicazione cosi come la hai modificata in PC2 su tutti
    i PC che vuoi
    ___ POTRAI INSTALLARLA ANCHE SU PC1
    Tutte le applicazioni andranno a cercare e modificare i dati sul DB di PC1  pertanto
    ogni modifica fatta da chiunque sara condivisa con tutti

    Inutile dirti che PC1 DEVE essere acceso per far funzionare le applicazioni
    sugli altri PC

    Nel gergo  PC1 si chiama Server
    Gli altri PC si chiamano Client

    Spero di essere stato utile

    Ciao. In effetti avevo un pò di eccessiva confusione sull'argomento. Ora mi sembra tutto più chiaro e forse anche semplice. Cambiando la stringa di connessione 'DataSource' dalle impostazioni del sorgente, che attualmente è: DataSource=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\LTSQUITMG.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True con un'altra che punta al server, non dovrei aver problemi. Ti chiedo solo un consiglio, se puoi darmelo. Nel sito connection string.com ne ho trovate parecchie, ma non so bene quale usare. Tu cosa useresti? Ho inoltre letto che occorre autenticare Sql Server con autenticazione mista, e non solo di Windows, con relativa password. E' vero o posso farne a meno? Grazie e ciao

    sabato 21 aprile 2012 20:18
  • Ho inoltre letto che occorre autenticare Sql Server con autenticazione mista,
    e non solo di Windows, con relativa password.
    E' vero o posso farne a meno? Grazie e ciao

    Esiste:

    Autenticazione di SQLServer e Autenticazione Mista  
    ( Dove Mista significa Autenticazione di SQLServer + Autenticazione di Windows )

    ________________________________________________________________________

    Io preferisco autenticazione di SQLServer perche molto piu certa nel funzionamento.
    Tu hai un utente e una pass  li metti nella stringa di connessione e vai tranquillo

    L'utente solitamente è "sa"
    la pass solitamente è quella digitata in fase di installazione di SQLServer

    __________

    L'autenticazione di Windows è invece una specie di ByPass con cui tu autorizzi SQLServer a considerare
    attendibile chiunque si sua gia logato correttamente in Windows.

    Ma poi ti cambia se questo qualcuno non è piu amministratore del PC
    Ti cambia se cambi tipo di rete
    Ti cambia per tante altre cose che alla fine ti fanno preferire la autenticazione di SQLServer

    _________________

    Diciamo che comunque entrambe le autenticazioni vanno bene.

    Quella di Windows è consigliabile se non vuoi esporre la pass di SQLServer nella stringa di connessione della applicazione

    Quella di SQLServer è obbligatoria se ti devi connettere con macchine NON Windows ( quindi non funzionerebbe quella di Windiws )
    ed è consigliabile se vuoi un funzionamento certo e non ti interessa esporre la password nei Client

    



    • Modificato Mancini, sabato 21 aprile 2012 21:49
    sabato 21 aprile 2012 21:18
  •  che attualmente è: DataSource=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\LTSQUITMG.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True con un'altra che punta al server, non dovrei aver problemi. Ti chiedo solo un consiglio, se puoi darmelo. Nel sito connection string.com ne ho trovate parecchie, ma non so bene quale usare. Tu cosa useresti?

    Ho usato visual basic pochissimo  quindi ti rispondo molto a SENSAZIONE
    e per analogia con ASP 
    Magari qualcuno piu esperto potra correggermi.

    ________________________________________________________________________________________________

    In ASP per esempio hai un file " WebConfiguration" dove puoi definire la stringa di connessione generale della applicazione
    Poi nella applicazione quando devi cercare dati fai riferimento alla stringa di connessione generale del file WebConfiguration

    In questo modo se sposti il DataBase ti basta modificare solo la stringa generale del WebConfiguration

    ________

    Naturalmente avresti potuto anche NON definire nessuna stringa nel WebConfiguration 
    bensi definire invece la stringa nella applicazione dovunque ti servisse

    In quest'altro modo se sposti il DataBase devi correggerti la stringa dappertutto

    ________

    Poi ci sono i piu "casinisti" che usamo un sistema misto !!!!

    _____________________________________________________________________________

    Ripeto  NON so se ASP sia simile a VB
    _____________________________________________________________________________

    Secondo me devi testarti la applicazione e correggere le stringhe necessarie
    Magari prova a postare un'altra domanda nel Forum di VB

    Saluti


    • Modificato Mancini, sabato 21 aprile 2012 21:41
    sabato 21 aprile 2012 21:36
  • salve,

    Ciao. In effetti avevo un pò di eccessiva confusione sull'argomento. Ora mi sembra tutto più chiaro e forse anche semplice. Cambiando la stringa di connessione 'DataSource' dalle impostazioni del sorgente, che attualmente è: DataSource=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\LTSQUITMG.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True con un'altra che punta al server, non dovrei aver problemi. Ti chiedo solo un consiglio, se puoi darmelo. Nel sito connection string.com ne ho trovate parecchie, ma non so bene quale usare. Tu cosa useresti? Ho inoltre letto che occorre autenticare Sql Server con autenticazione mista, e non solo di Windows, con relativa password. E' vero o posso farne a meno? Grazie e ciao


    qui "abbiamo un problema", non irrisolvibile, ma un problema c'e'... :)

    la tua attuale stringa di connessione prevede l'utilizzo di una User Instance, che come gia' ben sai, non permette connessioni remote da altri computer... quindi tutta la tua strategia, su "tutti i computer" deve cambiare per utilizzare non gia' la User Instance bensi' l'istanza "tradizionale" di SQL Server\SQLExpress; cio' ti consentira' sia connessioni locali che connessioni remote... come gia' Renarig ha detto, questo non e' di per se' un grosso problema, anche per il deploy, che come gia' avete affrontato, richiede "solo" che l'istanza di SQL Server\SQLExpress venga installata su 1 sola macchina, e che tutte le macchine "puntino" a quell'istanza... dovrai quindi anche rimuovere la proprieta' AttachDbFileName in quanto sara' buona prassi che tu registri i tuoi database al momento dell'installazione dell'istanza stessa... anche il deploy tramite ClickOnce putroppo ti verra' meno, ma potrai ad esempio benissimo passare a Wix, come anche a InnoSetup o altro strumento di generazioni di pacchetti di installazione "tradizionali", o anche l'installer "nativo" delle versioni "professionali" di Visual Studio...

    se utilizzi una versione Express di Visual Studio, abbandonare le User Instances ti comportera' anche l'impossibilita' di utilizzare i designers integrati di Visual Studio, che possono solo connettersi a "database SQL Server" (e quindi utilizzando solo la funzionalita' delle User Instances), ma ovviamente nulla vieta che tu utilizzi solo "puro codice" al loro posto...

    per quanto riguarda l'installazione dell'applicazione, il tutto risulta niente di particolarmente difficile, mentre diverso e' il caso dell'installazione, ad esempio, di SQLExpress... anche questo puo' in un qualche modo essere integrato nei pacchetti, anche se personalmente preferisco di gran lunga fare si che venga utilizzato il package "tradizionale" di SQLExpress, senza chiamate in shell e senza utilizzare i moduli di merge... il setup di SQLExpress e' relativamente semplice da utilizzare e non necessita' di particolari indicazioni se non per quanto eventualmente riguarda la necessita', spesso richiesta in ambiti WorkGroup (senza dominio), di abilitare anche l'autenticazione Mista (quindi permettendo sia autenticazioni WinNT [integrated security=true] che tramite login SQL Server tradizionali) e forse la collation di default dell'istanza (laddove necessario)...

    detto cio', dovrai anche predisporre, a livello applicativo, di poter specificare il server (l'istanza SQL Server\SQLExpress) che dovra' essere utilizzata tramite apposito dialogo, in modo da poter cosi' calibrare la connection string specifica per ogni singola macchina... come ben sai, diventa cosi' "difficile" trovare un posto sul file system dove ospitare il file di configurazione che mantenga questa informazione di connessione, "posto" accessibile in lettura/scrittura per tutti gli utenti di ogni singola macchina (laddove richiesto), mentre ovviamente in caso di assenza di questa esigenza generale il posizionamento in %appdata% va benissimo...

    per quanto riguarda la tipologia di autenticazione, Renarig ti ha correttamente indicato che l'autenticazione integrata WinNT sarebbe da preferire, ma questo spesso diventa un problema in assenza di un dominio (quindi in un WorkGroup)... spesso si utilizza un sistema di "inganno", generando su tutte le macchine coinvolte "tutte le login" del workgroup, quindi utilizzando un workaround di "impersonificazione"...  sulla macchina A saranno presenti le login di A\MauriVbe, A\Renarig, A\Andrea, mentre la macchina B avra' disponibili le login B\MauriVbe, B\Renarig, B\Andrea eccetera... quando B\Andrea tentera' di connettersi al server A, gli passera' la propria id di B\Andrea, e molto spesso (ma non sempre, attenzione), lo stack di rete riesce a mascherare B\Andrea in A\Andrea, quindi consentendo anche l'autenticazione all'istanza SQL Server (sempre che sull'istanza SQL Server siano state "registrate" le login locali A\MauriVbe, A\Renarig, A\Andrea o il loro gruppo WinNT di appartenenza)... il caveat e' ovviamente che non esiste un domain controller che gestisca veramente la cosa, ma il tutto "sta in piedi per quasi fortuna"... non e' garantito che prossime versioni del sistema operativo continuino a supportare questo workaround... spesso quindi, in ambiente WorkGroup si decade sull'autenticazione standard SQL Server... la tua gestionalita' potrebbe pero' ovviamente prevedere entrambe le funzionalita'...

    tornando alla "migrazione dalle User Instance", Roger indica abbastanza "superficialmente" in http://technet.microsoft.com/en-us/library/bb264564(v=sql.90).aspx#sqlexpuser_topic12 la prassi da seguire, ma ricorda che in ambiente SQL Server dovresti gestire tutta la "problematica" della sicurezza in maniera corretta, senza il "beneficio" dell'accesso garantito agli oggetti che ottenevi di default nell'altro ambiente, quindi, nuovamente, la parte di autenticazione (le login), la parte di accesso ai database (i database user) e la parte di accesso ai singoli oggetti table/viste/procedures...  nulla di insormontabile, ma tienilo presente, ricordandoti anche di referenziare gli oggetti (viste, tabelle, etc) sempre utilizzando il nome completo (schema.oggetto) in modo da non incorrere in subdole problematiche di incertezza come anche di non subire penalizzazioni prestazionali relative alla necessita' da parte del query optimizer di identificare "quale" tabella/vista/.. tu stia in effetti referenziano, problematica che a tutti gli effetti si risolve a runtime con l'ulteriore penalizzazione dell'impossibilita' di riutilizzare i piani di esecuzione gia' compilati...

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    sabato 21 aprile 2012 23:31
    Moderatore
  • salve,

    >Io preferisco autenticazione di SQLServer perche molto piu certa nel funzionamento.

    attenzione che questo richiede esplicitamente che tale tipo di autenticazione sia stata abilitata, al momento dell'installazione o anche successivamente, ma non e' un'impostazione di default, e quindi richiede un esplicito intervento manuale.. per chiarire, anche io comunque preferenzialmente la utilizzo in ambiti WorkGroup...

    >Tu hai un utente e una pass  li metti nella stringa di connessione e vai tranquillo

    >L'utente solitamente è "sa"

    io spero molto che tu stia scherzando :) .... non mi pare proprio ne' cosa da fare ne' buon consiglio dire di utilizzare "sa" come login interattiva normale.... le login di tipo amministrativo vanno utilizzate solo quando necessario e non nel normale corso interattivo applicativo... se poi ci si fa del male, inutile dire "te l'avevo detto" :)

    per favore, se lo fai, almeno non consigliarlo in giro ... :)

    >L'autenticazione di Windows è invece una specie di ByPass con cui tu autorizzi SQLServer a considerare
    >attendibile chiunque si sua gia logato correttamente in Windows.

    questo non e' completo... come hai detto, "l'autenticazione integrata fa riconoscere attendibile chiunque sia correttamente loggato in Windows o nel dominio", ma questo non e' sufficiente di per se.. e' anche necessario che alla login WinNT o al gruppo WinNT di cui la login e' membro siano stati garantiti privilegi di autenticazione all'istanza SQL Server... al momento dell'installazione di SQL Server e' possibile aggiungere tra i principals dell'istanza alcuni GruppiNT o LoginNT, ma cio' nulla toglie alla richiesta specifica di autenticazione... che richiede appunto la garanzia del privilegio di autenticazione...

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    sabato 21 aprile 2012 23:46
    Moderatore
  • per favore, se lo fai, almeno non consigliarlo in giro ... :)

    Hai ragione,
    La prossima volta staro piu attento

    Saluti

    domenica 22 aprile 2012 19:04
  • salve,

    Ciao. In effetti avevo un pò di eccessiva confusione sull'argomento. Ora mi sembra tutto più chiaro e forse anche semplice. Cambiando la stringa di connessione 'DataSource' dalle impostazioni del sorgente, che attualmente è: DataSource=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\LTSQUITMG.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True con un'altra che punta al server, non dovrei aver problemi. Ti chiedo solo un consiglio, se puoi darmelo. Nel sito connection string.com ne ho trovate parecchie, ma non so bene quale usare. Tu cosa useresti? Ho inoltre letto che occorre autenticare Sql Server con autenticazione mista, e non solo di Windows, con relativa password. E' vero o posso farne a meno? Grazie e ciao


    qui "abbiamo un problema", non irrisolvibile, ma un problema c'e'... :)

    la tua attuale stringa di connessione prevede l'utilizzo di una User Instance, che come gia' ben sai, non permette connessioni remote da altri computer... quindi tutta la tua strategia, su "tutti i computer" deve cambiare per utilizzare non gia' la User Instance bensi' l'istanza "tradizionale" di SQL Server\SQLExpress; cio' ti consentira' sia connessioni locali che connessioni remote... come gia' Renarig ha detto, questo non e' di per se' un grosso problema, anche per il deploy, che come gia' avete affrontato, richiede "solo" che l'istanza di SQL Server\SQLExpress venga installata su 1 sola macchina, e che tutte le macchine "puntino" a quell'istanza... dovrai quindi anche rimuovere la proprieta' AttachDbFileName in quanto sara' buona prassi che tu registri i tuoi database al momento dell'installazione dell'istanza stessa... anche il deploy tramite ClickOnce putroppo ti verra' meno, ma potrai ad esempio benissimo passare a Wix, come anche a InnoSetup o altro strumento di generazioni di pacchetti di installazione "tradizionali", o anche l'installer "nativo" delle versioni "professionali" di Visual Studio...

    se utilizzi una versione Express di Visual Studio, abbandonare le User Instances ti comportera' anche l'impossibilita' di utilizzare i designers integrati di Visual Studio, che possono solo connettersi a "database SQL Server" (e quindi utilizzando solo la funzionalita' delle User Instances), ma ovviamente nulla vieta che tu utilizzi solo "puro codice" al loro posto...

    per quanto riguarda l'installazione dell'applicazione, il tutto risulta niente di particolarmente difficile, mentre diverso e' il caso dell'installazione, ad esempio, di SQLExpress... anche questo puo' in un qualche modo essere integrato nei pacchetti, anche se personalmente preferisco di gran lunga fare si che venga utilizzato il package "tradizionale" di SQLExpress, senza chiamate in shell e senza utilizzare i moduli di merge... il setup di SQLExpress e' relativamente semplice da utilizzare e non necessita' di particolari indicazioni se non per quanto eventualmente riguarda la necessita', spesso richiesta in ambiti WorkGroup (senza dominio), di abilitare anche l'autenticazione Mista (quindi permettendo sia autenticazioni WinNT [integrated security=true] che tramite login SQL Server tradizionali) e forse la collation di default dell'istanza (laddove necessario)...

    detto cio', dovrai anche predisporre, a livello applicativo, di poter specificare il server (l'istanza SQL Server\SQLExpress) che dovra' essere utilizzata tramite apposito dialogo, in modo da poter cosi' calibrare la connection string specifica per ogni singola macchina... come ben sai, diventa cosi' "difficile" trovare un posto sul file system dove ospitare il file di configurazione che mantenga questa informazione di connessione, "posto" accessibile in lettura/scrittura per tutti gli utenti di ogni singola macchina (laddove richiesto), mentre ovviamente in caso di assenza di questa esigenza generale il posizionamento in %appdata% va benissimo...

    per quanto riguarda la tipologia di autenticazione, Renarig ti ha correttamente indicato che l'autenticazione integrata WinNT sarebbe da preferire, ma questo spesso diventa un problema in assenza di un dominio (quindi in un WorkGroup)... spesso si utilizza un sistema di "inganno", generando su tutte le macchine coinvolte "tutte le login" del workgroup, quindi utilizzando un workaround di "impersonificazione"...  sulla macchina A saranno presenti le login di A\MauriVbe, A\Renarig, A\Andrea, mentre la macchina B avra' disponibili le login B\MauriVbe, B\Renarig, B\Andrea eccetera... quando B\Andrea tentera' di connettersi al server A, gli passera' la propria id di B\Andrea, e molto spesso (ma non sempre, attenzione), lo stack di rete riesce a mascherare B\Andrea in A\Andrea, quindi consentendo anche l'autenticazione all'istanza SQL Server (sempre che sull'istanza SQL Server siano state "registrate" le login locali A\MauriVbe, A\Renarig, A\Andrea o il loro gruppo WinNT di appartenenza)... il caveat e' ovviamente che non esiste un domain controller che gestisca veramente la cosa, ma il tutto "sta in piedi per quasi fortuna"... non e' garantito che prossime versioni del sistema operativo continuino a supportare questo workaround... spesso quindi, in ambiente WorkGroup si decade sull'autenticazione standard SQL Server... la tua gestionalita' potrebbe pero' ovviamente prevedere entrambe le funzionalita'...

    tornando alla "migrazione dalle User Instance", Roger indica abbastanza "superficialmente" in http://technet.microsoft.com/en-us/library/bb264564(v=sql.90).aspx#sqlexpuser_topic12 la prassi da seguire, ma ricorda che in ambiente SQL Server dovresti gestire tutta la "problematica" della sicurezza in maniera corretta, senza il "beneficio" dell'accesso garantito agli oggetti che ottenevi di default nell'altro ambiente, quindi, nuovamente, la parte di autenticazione (le login), la parte di accesso ai database (i database user) e la parte di accesso ai singoli oggetti table/viste/procedures...  nulla di insormontabile, ma tienilo presente, ricordandoti anche di referenziare gli oggetti (viste, tabelle, etc) sempre utilizzando il nome completo (schema.oggetto) in modo da non incorrere in subdole problematiche di incertezza come anche di non subire penalizzazioni prestazionali relative alla necessita' da parte del query optimizer di identificare "quale" tabella/vista/.. tu stia in effetti referenziano, problematica che a tutti gli effetti si risolve a runtime con l'ulteriore penalizzazione dell'impossibilita' di riutilizzare i piani di esecuzione gia' compilati...

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    Ciao. Ti ringrazio per la risposta, ma temo che per me ormai sia molto complicato gestire la cosa. Ho provato a modificare la stringa di connessione, che ho fatto attraverso un file udl, e mi è venuta:

    "Integrated Security=SSPI;Persist Security Info=False;User ID="";Initial Catalog=LTSQUITMG;Data Source=MAURI-PC;Initial File Name=""

    che mi funziona, cioè connette il DB. Ma ciò è solo codice nel form. Se cancello Attach e UserInstances dalla stringa originale nel file app.config non mi funziona più niente. Sicuramente sbaglio q.sa, ma sinceramente non ho voglia di riscrivere tutto il codice. Ho letto decine e decine di form, e le variabili in gioco sono un pò troppe, a partire dall'account, dall'autenticazione, ecc, ecc..  Amen, proverò altre strade. Grazie lo stesso

    lunedì 23 aprile 2012 11:33
  • salve,

    Ciao. Ti ringrazio per la risposta, ma temo che per me ormai sia molto complicato gestire la cosa. Ho provato a modificare la stringa di connessione, che ho fatto attraverso un file udl, e mi è venuta:

    "Integrated Security=SSPI;Persist Security Info=False;User ID="";Initial Catalog=LTSQUITMG;Data Source=MAURI-PC;Initial File Name=""

    che mi funziona, cioè connette il DB. Ma ciò è solo codice nel form. Se cancello Attach e UserInstances dalla stringa originale nel file app.config non mi funziona più niente. Sicuramente sbaglio q.sa, ma sinceramente non ho voglia di riscrivere tutto il codice. Ho letto decine e decine di form, e le variabili in gioco sono un pò troppe, a partire dall'account, dall'autenticazione, ecc, ecc..  Amen, proverò altre strade. Grazie lo stesso

    non volevo "spaventare nessuno" :)...

    comunque non e' cosi' "complicato"... il fatto che sulle macchine "finali" la cosa non funziona probabilmente dipende dal fatto che il tuo database non e' registrato sull'istanza che funge da server aziendale... con le User Instance provvedevi in "automagico" tramite la proprieta' AttachDbFileName, ma ora devi in un qualche modo provvedere "manualmente".... esistono vari sistemi, dal "restore fisico" di un file di backup tramite l'istruzione RESTORE DATABASE ... WITH MOVE ... (vedi la sintassi sui BOL) come anche l'attacco di un file di database tramite l'istruzione CREATE DATABASE ... FOR ATTACH... (vedi sempre i BOL)... un altro sistema e' provvedere un apposito package di setup, ad esempio il prodotto di Red Gate provvede in tal senso, ed e' anche in grado di gestirti la post produzione, il momento cioe' in cui dovrai effettuare il deploy di un aggiornamento allo schema del database... personalmente preferisco soluzioni piu' sotto il "mio" controllo, soluzioni comunque di tipo tradizionale, dove devi provvedere a distribuire gli script di creazione del database e degli oggetti che lo compongono... un ottimo articolo in tal senso lo trovi in http://www.simple-talk.com/sql/database-administration/deploying-database-developments/ come anche http://msdn.microsoft.com/it-it/magazine/cc163919(en-us).aspx ... queste soluzioni consento ovviamente la gestione del versioning della base dati... di nuovo, personalmente, utilizzo un componente addizionale che si occupa del tutto, cioe' di installare (in base agli script di creazione) i database necessari, come anche di aggiornarli nel momento di pubblicazione degli script di aggiornamento... sembra tutto molto complicato, ma in effetti non lo e'... e ti risolve un problema che prima o poi dovrai in effetti sempre affrontare...

    tornando alla stringa di connessione, rimuovi la proprieta' "Initial File Name=""" ... visto che hai indicato una connessione trusted, rimuovi anche "User ID ="""...

    ripeto, sembra complicato, ma basta comprenderne le funzionalita'... non stai piu' parlando di connetterti direttamente ad un file di database, ma ti connetti ad un servizio che ti espone dei database da utilizzare... perdi in semplicita' (AttachDbFileName) ma guadagni in sicurezza e accessibilita' ....  diversamente resti legato a scenari monoutente quali ora utilizzati..

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    lunedì 23 aprile 2012 15:18
    Moderatore
  • salve,

    non volevo "spaventare nessuno" :)...

    comunque non e' cosi' "complicato"... il fatto che sulle macchine "finali" la cosa non funziona probabilmente dipende dal fatto che il tuo database non e' registrato sull'istanza che funge da server aziendale... con le User Instance provvedevi in "automagico" tramite la proprieta' AttachDbFileName, ma ora devi in un qualche modo provvedere "manualmente".... esistono vari sistemi, dal "restore fisico" di un file di backup tramite l'istruzione RESTORE DATABASE ... WITH MOVE ... (vedi la sintassi sui BOL) come anche l'attacco di un file di database tramite l'istruzione CREATE DATABASE ... FOR ATTACH... (vedi sempre i BOL)... un altro sistema e' provvedere un apposito package di setup, ad esempio il prodotto di Red Gate provvede in tal senso, ed e' anche in grado di gestirti la post produzione, il momento cioe' in cui dovrai effettuare il deploy di un aggiornamento allo schema del database... personalmente preferisco soluzioni piu' sotto il "mio" controllo, soluzioni comunque di tipo tradizionale, dove devi provvedere a distribuire gli script di creazione del database e degli oggetti che lo compongono... un ottimo articolo in tal senso lo trovi in http://www.simple-talk.com/sql/database-administration/deploying-database-developments/ come anche http://msdn.microsoft.com/it-it/magazine/cc163919(en-us).aspx ... queste soluzioni consento ovviamente la gestione del versioning della base dati... di nuovo, personalmente, utilizzo un componente addizionale che si occupa del tutto, cioe' di installare (in base agli script di creazione) i database necessari, come anche di aggiornarli nel momento di pubblicazione degli script di aggiornamento... sembra tutto molto complicato, ma in effetti non lo e'... e ti risolve un problema che prima o poi dovrai in effetti sempre affrontare...

    tornando alla stringa di connessione, rimuovi la proprieta' "Initial File Name=""" ... visto che hai indicato una connessione trusted, rimuovi anche "User ID ="""...

    ripeto, sembra complicato, ma basta comprenderne le funzionalita'... non stai piu' parlando di connetterti direttamente ad un file di database, ma ti connetti ad un servizio che ti espone dei database da utilizzare... perdi in semplicita' (AttachDbFileName) ma guadagni in sicurezza e accessibilita' ....  diversamente resti legato a scenari monoutente quali ora utilizzati..

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/


    Ciao. No, tranquillo, non mi sono spaventato. Solo un pò demoralizzato. E cmq, con "non funziona più niente", intendevo l'applicazione. Cioè, rimuovendo Attach e Userinstance, la compilazione del programma va in errore grave, perché non riesce manco ad aprire il form iniziale. E' qui che manco di conoscenza. Cioè: la stringa di cui sopra va scritta solo nel codice del form all'avvio per aprire la connessione? Ma le altre stringhe, contenute in App.config e nel file Setting.designer.Vb, dove c'è Attach e Userinstance, vanno cambiate? Se le cambio si blocca tutto. E' qui mi manca un passaggio. Perché nel momento che creo una nuova connessione da wizard (Esplora Database), e punto al database che è presente in Sql Server, la connessione è ok, ma la stringa che crea in automatico il programma contiene Attach e Userinstance, quindi sono da capo. Quindi, cosa devo fare?
    • Modificato maurivbe lunedì 23 aprile 2012 17:02
    lunedì 23 aprile 2012 17:01
  • salve,

    Ciao. No, tranquillo, non mi sono spaventato. Solo un pò demoralizzato. E cmq, con "non funziona più niente", intendevo l'applicazione. Cioè, rimuovendo Attach e Userinstance, la compilazione del programma va in errore grave, perché non riesce manco ad aprire il form iniziale. E' qui che manco di conoscenza. Cioè: la stringa di cui sopra va scritta solo nel codice del form all'avvio per aprire la connessione? Ma le altre stringhe, contenute in App.config e nel file Setting.designer.Vb, dove c'è Attach e Userinstance, vanno cambiate? Se le cambio si blocca tutto.

    ok :)

    direi che devi cominciare ad analizzare le cause della mancata compilazione, cioe' identificare tutti gli errori... relativamente alle altre stringhe di connessione, "...non vanno cambiate..."... ma addirittura "non vanno assolutamente utilizzate" in quanto punterebbero al tuo file di database locale attivando una user instance.... ogni volta che dovrai aprire una connessione alla base dati dovrai utilizzare la tua nuova stringa di connessione che hai codificato (e che ovviamente deve anche essere modificabile e parametrizzabile in modo da puntare sempre all'istanza SQL Server da te in uso)....

    E' qui mi manca un passaggio. Perché nel momento che creo una nuova connessione da wizard (Esplora Database), e punto al database che è presente in Sql Server, la connessione è ok, ma la stringa che crea in automatico il programma contiene Attach e Userinstance, quindi sono da capo. Quindi, cosa devo fare?

    come inizialmente avevo indicato, qui comincia subito il problema... i designer integrati delle versioni Express di Visual Studio possono solo operare nei confronti di "File di database .mdf" e non direttamente nei confronti di un'istanza tradizionale di SQL Server... purtroppo non li puoi' piu' usare.. va "tutto fatto a mano"... creazione della stringa di connessione, popolamento degli adapter/reader che poi sottointendono il "funzionamento" di Linq2Sql, ..... sicuramente "un lavoraccio", ma l'unico che ti permetta di utilizzare una "condivisione" a livello di base di dati..

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    lunedì 23 aprile 2012 22:08
    Moderatore
  • E' qui mi manca un passaggio. Perché nel momento che creo una nuova connessione da wizard (Esplora Database), e punto al database che è presente in Sql Server, la connessione è ok, ma la stringa che crea in automatico il programma contiene Attach e Userinstance, quindi sono da capo. Quindi, cosa devo fare?

    come inizialmente avevo indicato, qui comincia subito il problema... i designer integrati delle versioni Express di Visual Studio possono solo operare nei confronti di "File di database .mdf" e non direttamente nei confronti di un'istanza tradizionale di SQL Server... purtroppo non li puoi' piu' usare.. va "tutto fatto a mano"... creazione della stringa di connessione, popolamento degli adapter/reader che poi sottointendono il "funzionamento" di Linq2Sql, ..... sicuramente "un lavoraccio", ma l'unico che ti permetta di utilizzare una "condivisione" a livello di base di dati..

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    Ciao. Credo di vedere un pò di luce in fondo al tunnel! Ho provato un piccolo codice, che allego con la stringa di prima, che punta ad un db creato direttamente in Sql Server con SSMS, con una sola tabella, tanto per provare.

    Imports System.Data.SqlClient

    Public Class Form1

       Private sqcl1 As New SqlConnection

       Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load

          Me.sqcl1.ConnectionString = _

              "Integrated Security=SSPI;Persist Security Info=False;User ID=Mauri-PC\Mauri;Initial Catalog=QUITNEW;Data Source=MAURI-PC"

          Me.sqcl1.Open()

         Dim sql = "SELECT COUNT (Cartella) AS Num FROM Tabella"

          Dim Comando As New SqlCommand(sql, Me.sqcl1)

          Dim Num = CType(Comando.ExecuteScalar, Integer)

          MessageBox.Show(Me, Num.ToString)

          If Num = 0 Then

             sql = "INSERT INTO TabFolderClientiNoah (Cartella) VALUES ('PIPPO')"

             Comando = New SqlCommand(sql, Me.sqcl1)

             Num = CType(Comando.ExecuteNonQuery, Integer)

          Else

             sql = "SELECT (Cartella) FROM Tabella"

             Comando = New SqlCommand(sql, Me.sqcl1)

             Dim rec As SqlDataReader = Comando.ExecuteReader

             While rec.Read

                MessageBox.Show(Me, rec("Cartella").ToString)

             End While

          End If

          Me.sqcl1.Close()

          Me.Close()

       End Sub

    End Class

    In sorgente gira perfettamente. Pubblicato con clickonce, avevo problemi di autorizzazione dei comandi sql. Ho abilitato l'utente come dbowner del db, e ora tutto funziona. Ora ti chiedo solo ancora 2 cose. Nella stringa del programma che installerò sui 2 client, al posto di "User ID=Mauri-PC\Mauri, devo mettere l'account del pc client, e quindi abilitare anche lui per poter modificare il db? E poi, VStudio Professional è sufficiente per accedere direttamente nei confronti di un'istanza tradizionale di SQL Server, o occorre Ultimate? Ciao e ancora grazie per le tue risposte

    martedì 24 aprile 2012 08:06
  • salve,

          Me.sqcl1.ConnectionString = _

              "Integrated Security=SSPI;Persist Security Info=False;User ID=Mauri-PC\Mauri;Initial Catalog=QUITNEW;Data Source=MAURI-PC"

    In sorgente gira perfettamente. Pubblicato con clickonce, avevo problemi di autorizzazione dei comandi sql. Ho abilitato l'utente come dbowner del db, e ora tutto funziona. 


    togli la parte "User ID=Mauri-PC\Mauri", che a tutti gli effetti confonde te e puo' portare in errore lo stack di connessione... hai impostato Integrated Security=SSPI, che indica una connessione con autenticazione Windows, quindi non devi fornire alcuna altra credenziale di accesso... il sistema operativo (dovrebbe essere il domain controller, ma in un WorkGroup non c'e') passa a SQL Server l'hash della login corrente, che provvede a valutare se a quest'ultima (o al gruppo WinNT del quale fa parte) sia stata autorizzata alla connessione.. in caso affermativo si procede oltre con le 2 rimanenti fasi di autorizzazione, che come abbiamo detto sono l'accesso ad uno specifico database (tramite l'associazione di un database user alla login) e successivamente di accesso agli oggetti specifici.... qui avevi problemi con i "comandi sql"... il database user associato alla login deve avere anche autorizzazioni esplicite di accesso/utilizzo degli oggetti, a meno che non sia membro del ruolo di database dbowner, cosa che non andrebbe impostata per gli account interattivi normali.. dovresti normalmente utilizzare login e quindi database users "limitati" nei privilegi... non impaurirti.. "all'inizio e' complicato davvero" :) ... ma poi, quando ti impratichisci con la filosofia di protezione, tutto diventa piu' chiaro e concettualmente corretto... come mai pensi che Linq2SQL come anche tutti gli ORM in circolazione siano cosi' invisi ai dba? molto spesso perche' non e' mai "esplicito" a livello di codice SQL l'accesso ai dati.. il layer intermedio si occupa di generare il codice SQL di interazione... diversamente, ai dba, piace avere un layer a loro visibile, tipicamente contenuto in stored procedures, che loro possono analizzare sia dal punto di vista della sicurezza che anche prestazionale, provvedendo magari a "manutenzioni prestazionali" quali aggiunte di indici e via dicendo.. ma soprattutto sanno che l'accesso (che potenzialmente e' sempre maligno agli occhi dei dba) e' circoscritto nelle stored procedures a loro note, e non sparso in magari centinaia di migliaia di righe di codice applicativo o, "peggio ancora", generato dinamicamente dagli ORM :)... infatti questa "metodologia" di accesso richiede che vengano sempre garantiti (potenzialmente a "tutti") privilegi di accesso diretto alle tabelle, dove invece (sia prestazionalmente che per sicurezza) si preferisce dare accesso solo alle stored procedure (e per i soli utenti che ne vantino diritto) che poi accederanno ai dati veri e propri... il percorso pare lungo, ma e' prudente, corretto, verificabile e manutenibile.. anche prestazionalmente.. :) ora basta che rischio gli insulti di qualche "DEV" :)

    ... Ora ti chiedo solo ancora 2 cose. Nella stringa del programma che installerò sui 2 client, al posto di "User ID=Mauri-PC\Mauri, devo mettere l'account del pc client, e quindi abilitare anche lui per poter modificare il db? E poi, VStudio Professional è sufficiente per accedere direttamente nei confronti di un'istanza tradizionale di SQL Server, o occorre Ultimate? Ciao e ancora grazie per le tue risposte

    di nuovo, niente "User ID"... dovrai primariamente aver garantito alle login di sistema operativo l'autenticazione all'istanza, e via di seguito con i database users... per semplificare, con un "piano di sicurezza minimo (anzi infimo)", tipicamente, a livello di sistema operativo, creerai un gruppo "UtentiSQL", del quale faranno parte "Mauri-PC\Mauri", "Mauri-PC\Andrea" (che lavorera' sulla macchina Andrea come "Andrea-PC\Andrea" e via di seguito... garantirai a livello SQL Server l'accesso all'istanza a questo gruppo NT... sul db interessato, genererai l'associazione Login->database user... creerai un database role "UtentiQUITNEW" e renderai membro di questo ruolo tutti i tuoi database user... al ruolo generato, garantirai privilegi di accesso ai dati, quindi privilegio SELECT/UPDATE/INSERT/DELETE per ogni singola tabella interessata [di nuovo, preferenzialmente solo privilegi di EXECUTE sulle stored procedure che accedono alle tabelle, ma restiamo "basilari":)]... il gioco e' fatto :)

    si, Visual Studio Professional non ha la limitazione sui designers integrati che hanno le versioni Express..

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    martedì 24 aprile 2012 23:07
    Moderatore
  • Ciao. Spero con questa ultima domanda di risolvere il tutto! Innanzitutto ti chiedo scusa, perché ti ho tratto in inganno con la stringa precedente, ed in particolare con "Integrated Security=SSPI", che come hai detto tu, fa accedere come Windows Authentication ma, come ho letto in giro, funziona solo se i pc sono in un dominio, cosa che io non ho. Si potrebbe farla funzionare lo stesso anche  in un Workgroup (gruppo home), ma sembra sia una cosa non ortodossa e non sicura. Quindi, alla fine, per tagliare la testa al toro, ho acquistato VStudio Professional, l'ho installato, e ho creato un'applicazione nuova, ma usando tutte le form del progetto scritto in VBasic Express, semplicemente importando il progetto e spostando tutte le form nel nuovo progetto. Poi, ho creato la connessione con il database (ovviamente attraverso Microsoft Sql Server, e non File di Database di Microsoft Sql Server), ho eseguito test di connessione e tutto fila liscio. La stringa di connessione che VSTUDIO ha generato è:

    Data Source=MAURI-PC\SQLEXPRESS;Initial Catalog="QUITNEW";Integrated Security=True

    Ho creato la classe LinqToSql, generato tutte le origini dei dati, e al primo colpo la compilazione è andata a buon fine. Ho pubblicato il programma sempre con ClickOnce, e lanciando il file .exe tutto va bene. Ora, siamo di nuovo allo stesso punto. Cioè, non avendo un dominio, devo autenticare la connessione a livello di wizard in VStudio con "Autenticazione di SQL Server" e relativa password? E devo fare la stessa cosa da SSMS, quando vi accedo e mi chiede come voglio connettermi? Se si, devo quindi fare i seguenti passaggi ?

    1) creare un nuovo account di accesso (tasto destro mouse in SSMS/Sicurezza/account di accesso/Nuovo account di accesso) e nella finestra che si apre, creare un account, con autenticazione di SQL Server con relativa pw, selezionare nel link "Database predefinito" QUITNEW, e dare ok

    2) tornare in VSudio e autenticare la connessione di SQL Server con lo stesso account creato prima

    3) installare sui client il programma

    E' corretto, o manca ancora q.sa ?  Grazie di tutto

    Aggiornamentoo delle ore 17:10 Ho fatto quanto sopra, ma quando lancio l'applicazione dal client, mi dice:

    "Accesso non consentito per l'utente Mauri-PC\Guest"

    Mi puoi illuminare su questo messaggio ? In Google mon ho trovato nulla che mi aiutasse

    • Modificato maurivbe mercoledì 25 aprile 2012 15:12
    mercoledì 25 aprile 2012 09:49
  • salve,

    .... Ho pubblicato il programma sempre con ClickOnce, e lanciando il file .exe tutto va bene. Ora, siamo di nuovo allo stesso punto. Cioè, non avendo un dominio, devo autenticare la connessione a livello di wizard in VStudio con "Autenticazione di SQL Server" e relativa password? E devo fare la stessa cosa da SSMS, quando vi accedo e mi chiede come voglio connettermi? Se si, devo quindi fare i seguenti passaggi ?

    1) creare un nuovo account di accesso (tasto destro mouse in SSMS/Sicurezza/account di accesso/Nuovo account di accesso) e nella finestra che si apre, creare un account, con autenticazione di SQL Server con relativa pw, selezionare nel link "Database predefinito" QUITNEW, e dare ok

    2) tornare in VSudio e autenticare la connessione di SQL Server con lo stesso account creato prima

    3) installare sui client il programma

    E' corretto, o manca ancora q.sa ?  Grazie di tutto


    ni... :)

    dai, tendenzialmente si... relativamente al database predefinito io preferisco sempre impostare il database di sistema master... vedi mai che, in futuro, tu aggiunga funzionalita' o rimuovi il database, la login ti generera' delle eccezioni se non trova piu' il database predefinito...

    per il resto, puo' andare... tecnicamente, nella macchina finale, dovresti generare 3 login SQL Server, una per per ognuna delle persone/macchine che si andranno a collegare... e di nuovo, ad ogni login sara' associato un database user che sara' membro di uno o piu' database roles, al fine della gestione delle autorizzazioni di accesso agli oggetti/dati... questo pero' implica che la tua applicazione abbia un dialogo dove l'utente fornisce le proprie credenziali... diversamente stai operando con una singola login che funge piu' o meno da application role... chiunque si connetta utilizzera' le credenziali di quell'unica login applicativa, che tu hai addirittura "codificato" nel codice sorgente dell'applicazione... ci puo' stare, non saresti ne' il primo ne' l'ultimo ad utilizzare questa soluzione, ma anche questa non e' proprio ortodossa... 

    Aggiornamentoo delle ore 17:10 Ho fatto quanto sopra, ma quando lancio l'applicazione dal client, mi dice:

    "Accesso non consentito per l'utente Mauri-PC\Guest"

    Mi puoi illuminare su questo messaggio ? In Google mon ho trovato nulla che mi aiutasse

    quell'eccezione continua a dire che la stringa di connessione contiene "Integrated Security=SSPI", la login di sistema operativo non e' riconosciuta, e quindi il processo tenta di autenticarti come Macchina\Guest, che presumibilmente (spero) hai anche disabilitato a livello di SQL Server... rimuovi quella proprieta' dalla stringa di connessione ;)

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    mercoledì 25 aprile 2012 22:20
    Moderatore
  • Aggiornamentoo delle ore 17:10 Ho fatto quanto sopra, ma quando lancio l'applicazione dal client, mi dice:

    "Accesso non consentito per l'utente Mauri-PC\Guest"

    Mi puoi illuminare su questo messaggio ? In Google mon ho trovato nulla che mi aiutasse

    quell'eccezione continua a dire che la stringa di connessione contiene "Integrated Security=SSPI", la login di sistema operativo non e' riconosciuta, e quindi il processo tenta di autenticarti come Macchina\Guest, che presumibilmente (spero) hai anche disabilitato a livello di SQL Server... rimuovi quella proprieta' dalla stringa di connessione ;)

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    Ciao. Avevo dimenticato di fare una nuova connessione al db da VStudio, dopo aver introdotto l'autenticazione Sql. Ho ricompilato il programma e ora la stringa è:

    Data Source=MAURI-PC\SQLEXPRESS;Initial Catalog=QUTNEW";User ID=hvhmauri

    Ho pubblicato nuovamente il programma, installato sul client, ma dà lo stesso errore di macchina\Guest. L'utente guest non è mai stato abilitato in Windows, mentre in SQL ho tolto la spunta al checkbox 'dbownwer'. Cosa devo ancora fare?

    Aggiornamento delle ore 22:55. Risolto! Il client vede finalmente il server! In pratica, e questo spero possa servire a chi si trova nella mia stessa situazione, e come me non ha molta esperienza, non è sufficiente riconnettersi con il wizard da "Esplora Server" di VStudio per cambiare la stringa, in quanto non la modifica nei file settings e app.config. Occorre andare su: 'Progetto\Proprietà(nome programma); poi nel tab di sinistra, cliccare sul link "Impostazioni". Compare nella prima riga la stringa di connessione creata. Cliccare nella finestrella 'Valore', e comparirà la classica icona quadrata con i 3 punti. Cliccarci sopra e apparirà il form di 'Proprietà connessione'. Vanno valorizzati tutti i campi (nome server, autenticazione sql server e relativa pw e nome del database). Poi cliccare su Test connessione per verifcare appunto che sia tutto ok, poi infine cliccare su 'OK'. Si vedrà che la stringa di connessione viene scritta nel 'Valore' e poi, se si vuole verificare, anche nei files Settings e App.config. A questo punto compilare, e poi pubblicare il programma. Infine installarlo sul client e tutto dovrebbe andare. La stringa dovrebbe essere simile a questa:

    Data Source=MAURI-PC\SQLEXPRESS;Initial Catalog=QUITNEW;Persist Security Info=True;User ID=hvhmauri;Passowrd=**********

    N.B.:  Il comando 'Persist Security Info=True', appare perchè, per mia comodità, ho flaggato 'Salva password'

    Ora proverò ancora altre cose, specialmente su SSMSE, che è uno strumento un pochettino ostico, giusto per impratichirmi meglio.

    Grazie infinite a Fabrizio, Renarig e Andrea per il loro contributo!


    • Modificato maurivbe giovedì 26 aprile 2012 21:20
    giovedì 26 aprile 2012 12:22