salve Yuri,
qwarz987 ha scritto:
Mi autorizza ad entrare nel mio Portale Personale (non sò se vi presente il libro di Griffin?..), riesco a leggere i record, ma non riesco ad aggiornarli.
ma ti viene segnalata un'eccezione, un errore, un qualche cosa?
non so se tu stia tra parentesi verificando il database giusto..
tutte le versioni Express di Visual Studio utilizzano tendenzialmente non gia' il servizio tradizionale di SQL Server\SQLExpress, bensi' utilizzano le User Instances, http://msdn.microsoft.com/en-us/library/bb264564.aspx ..
tra l'altro questo comporta il referenziare un file di database sul proprio file system, il proprio modello di database, che al momento dell'esecuzione dell'applicazione viene "copiato" nella directory di esecuzione dell'applicazione stessa.. questo comporta la sovrascrittura dei file di database eventualmente gia' presenti e quindi la percezione che gli aggiornamenti alla base dati non avvengano, in quanto il db di "sviluppo" viene sovrascritto dal modello referenziato.. e' quindi indicato verificare che, nella Solution Explorer di Visual Studio, il file modello di database abbia l'impostazione di proprieta' "Copy to output directory" = "Copy if newer" e non gia' "copy always"..
qwarz987 ha scritto:
Un'altro problema che non riesco ad installare Microsoft sql server 2008 management studio express. L'ho scaricato come parte di SQL ADV, poi ho scaricato un'altro file separato rilasciato da Ms a febbraio. Niente. Passa il test, installa i file di supporto, mi fa scegliere il servizio al quale aggiungere le funzionalità (sqlexpress) e poi... nessuna possibilità selezionare / deselezionare SSMSE. Quindi non ho la possibilità di impostare le autorizzazioni per sql server.
presso http://www.asql.biz/it/Articles.aspx, trovi delle mie esperienze relativamente alle installazioni di SQLExpress, SSMS, etc.. magari possono esserti di conforto e aiuto..
Domanda...
C'e una via di mezzo d'impostazioni per sql tra: Integrated Security=True, Integrated Security=SSPI, Trusted_Connection=Yes o nessuna stringa proprio?..
le prime 3 indicazioni che hai fatto riguardano tutte il tipo di autenticazione integrata, che come vedi puo' essere specificata in diversi modi.. ma tutte e 3 ottengono il medesimo risultato..
"nessuna stringa proprio", invece, non dovrebbe essere usata :)
Domanda...
Qual'è potrebbe essere il problema che non riesco ad installare SSMSE?.. C'e un'altro modo per impostare le autorizzazioni?.. Differenza tra TOSHIBA/Yuri, TOSHIBA/User, TOSHIBA/ASPNET ecc?.. Qual è procedimento per autorizzazione: Una pagina web generata da Visual Web Dev >> Dev server di Visual Web Dev >> SQL Server 2008 Express?..
le "autorizzazioni", al pari della stragrande maggioranza delle operazioni, possono ovviamente anche essere gestite "non visualmente" tramite opportuni "comandi" da eseguirsi magari tramite SqlCMD.exe, lo strumento a riga di comando di SQL Server..
vedo pero' che hai notevoli lacune in fatto di cosa in effetti le autorizzazioni siano, come funzionino, etc..
ti consiglierei un buon libro, ma sicuramente i BOL, http://msdn.microsoft.com/en-us/library/ms130214.aspx (i Books on Line, la guida ufficiale di SQL Server, disponibile anche in italiano presso http://www.microsoft.com/downloads/details.aspx?FamilyId=765433F7-0983-4D7A-B628-0A98145BCB97&displaylang=en) costituiscono la nerbatura della preparazione che devi acquisire..
una pagina web, di base, ha poco a che spartire con il servizio SQL Server... c'e' un servizio, SQL Server, che viene eseguito nel contesto di sicurezza a livello di sistema operativo.. e qui si delineano le prime implementazioni di sicurezza...
c'e' poi l'autenticazione.. cioe' la fase dove un utente, sia esso un altro servizio (IIS, un utente interattivo con una sua Windows login ovvero una login standard SQL Server, ....) tenta una connessione all'istanza SQL Server..
SQL Server valida le credenziali fornite, che nel caso di una login integrata sono costituite dal SID della login stessa (e quindi non viaggiano informazioni esplicite di autenticazione, bensi' un dato binario) restituito dal Domain Controller responsabile ovvero dal sistema operativo stesso in caso di assenza di dominio; nel caso invece di autenticazione standard SQL Server l'utente deve fornire manualmente le proprie credenziali, tipicamente "nome utente" e "password".. Queste informazioni vengono quindi, come detto, validate da SQL Server verificando che esista una login autorizzata (un server principal, come vedrai nei BOL) all'autenticazione.. finita questa prima fase con successo, entra in campo la seconda parte dell'implementazione di sicurezza.. la validazione di accesso ad ogni singolo database.. questa funzionalita' viene implementata generando dei "database users" che vengono mappati a delle login a livello di istanza.. cio' rende possibile, dopo l'autenticazione che abbiamo visto prima, l'accesso all'utente corrente allo specifico database a lui interessante.. in assenza della concessione di questa autorizzazione di accesso ad uno o piu' database registrati, l'utente esterno non potra' procedere oltre nel suo utilizzo di SQL Server..
a livello di ogni singolo database, viene implementata la terza fase della piattaforma di sicurezza.. la gestione dei privilegi di accesso ad ogni singolo oggetto all'interno dello stesso db, quindi tabelle, viste, stored procedures, etc.. per predefinizione, ogni database user viene reso membro di un "ruolo" a livello di database, il ruolo "public".. pensa ai ruoli indicatgivamente come ai vari ruoli disponibili a livello di sistema operativo.. vengono utilizzati al fine della manipolazione dei privilegi con una granularita' superiore..
tornando al ruolo "public", questi non vanta alcun privilegio nei confronti degli oggetti presenti nel database.. non potra' quindi interrogare tabelle o viste, eseguire stored procedures, ...
esistono dei ruoli predefiniti, sia a livello di istanza (che evantualmente raggruppano "login") che di database (che raggruppano "database users")..
a livello di db, oltre a "public", esistono "db_datareader" (che vanta privilegi di lettura su tutte le tabelle del db), "db_datawriter" (che vanta privilegi di scrittura su tutte le tabelle del db)..
quello che pero' dovresti implementare e' pero' non gia' l'utilizzo di questi 2 ultimi per l'accesso diretto ai dati ed alle tabelle, bensi' la gestione di ruoli "definiti dall'utente" (da chi disegna la base dati).. avrai magari quindi un ruolo "Executive", che raggruppa tutti gli appartenenti alla "direzione aziendale", un ruolo "Staff" che raggruppa gli appartenenti allo staff dirigenzialie, e cosi' via fino magari al ruolo "Magazzino", che raggruppa tutti gli impiegati appartenenti al settore "magazzino" stesso..
con un'architettura di questo tipo puoi ovviamente con migliore efficacia gestire "chi puo' accedere a cosa".. "accesso ai dati" che, tra l'altro, e non solo per convinzione personale ma diffusa (almeno a livello di dba e non di sviluppatori) andrebbe concesso esclusivamente tramite l'esecuzione di stored procedures e giammai tramite "SELECT/UPDATE/INSERT/DELETE" dirette sulle tabelle.. ma qui potremmo aprire "una guerra di religione" :)
e torniamo infine alla tua pagina web.. probabilmente IIS si incarica delle problematiche di autenticazione nei confronti dell'istanza.. quindi, TOSHIBA/ASPNET potrebbe (ma non necessariamente) essere appunto l'account che esegue il servizio IIS che dovra' essere validato da SQL Server...
poi ci sara' magari una tabella di mappatura di "utenti" tradizionali, i classici "pippo\pluto\paperino".. ma questi sono solitamente solo palliativi alla gestione integrata della sicurezza fatta da SQL Server.. il contesto di sicurezza resta sempre il medesimo, quello dell'account che accede all'istanza..
tutto questo se.... se non si utilizzano le User Instances :)
vedi comunque l'articolo di Roger Wolters indicato in apertura relativamente a questa "aberrazione" :)
Domanda...
Sinceramente parlando conosco un'po access ma poco sql. Non vorrei poi incasinare un'altra volta il pc. Aspetto la risposta od almeno un consiglio mirato dove posso rivolgermi senza perdere troppo tempo.
Grazie in anticipo.
Yuri.
non vorrei sembrarti sgarbato, ma ti consiglio di studiare attentamente i BOL, in quanto SQL Server non e' come Access.. e' in effetti una piattaforma completa, dove la sicurezza riveste un aspetto formale ed importante, che deve essere ben compreso prima di iniziare a "giocare" con il linguaggio.. almeno, IMVHO..
parti quindi da http://msdn.microsoft.com/en-us/library/bb510589.aspx ..
saluti ed auguri
