Newsgroup: it.comp.software.database
Titolo: SQL Server - credenziali di accesso alle tabelle: non ho capito una fava....

In un DB SQL Server ho creato delle utenze che devono avere determinate
limitazioni: una deve essere in grado di cancellare il contenuto delle
tabelle e ripopolarle, le altre devono solo leggere. Ho dunque settato le
utenze rispettivamente con le regole db_datawriter e db_datareader.
Ho poi delle routine che creano dei collegamenti da un DB Access alle
tabelle sul server. Se però provo ad aprire queste da Access, nel caso di
db_datawriter, si genera sempre un errore:
ODBC: chiamata non riuscita
[Microsoft][ODBC SQL Server Driver][SQL Server]SELECT permission denied on
object 'NomeTabella', database 'NomeDB',owner 'dbo'. (#229)
Nel caso di db_datareader, invece, i dati vengono correttamente visualizzati
in sola lettura.
In entrambi i casi, se visualizzo le credenziali per singola tabella non
risulta flaggato nulla. Ma se ho capito bene, se uso le Role i diritti sulla
singola tabella sono impostati di default, no?
Dove cappero sbaglio?
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 singola tabella sono impostati di default, no?
Nella singola tabella non vedi nulla, perché le autorizzazioni sono
impostate a livello di Ruolo.
-- 
David Martin

 singola tabella sono impostati di default, no?
Per i ruoli predefiniti i permessi non sono evidenziati tra le proprietà 
della tabella.
Non so se sono le tue intenzioni, ma gli utenti membri dei ruoli 
db_datareader/db_datawriter concedono il permesso di lettura/scrittura su 
TUTTE le tabelle e viste del database. Sarebbe preferibile invece che tu 
definisca uno o più database role, assegni loro i permessi necessari ed 
infine rendi membri di questi ruoli gli account necessari. Fai anche 
riferimento a questo mio articolo
http://www.microsoft.com/italy/technet/community/mvp/editoriali/permessi.mspx
Bye
-- 
Luca Bianchi
Microsoft MVP - SQL Server
http://blogs.aspitalia.com/lucabianchi/

 riferimento a questo mio articolo
Ti ringrazio, ma per i miei scopi attuali (e per la dimestichezza che ho con
l'oggetto) per ora mi va bene definire semplicemente chi può leggere e chi
scrivere. Poi specializzerò le utenze per tabella, ma quando mi saranno più
chiare certe dinamiche!


 chiare certe dinamiche!
E' tutto estremamente semplice. Basta fare comprendere i principi che sono 
alla base dell'assegnazione dei privilegi. Fai riferimento al Book OnLine di 
SQL Server per ulteriori e indispensabili approfondimenti...


 DELETE su tutte le tabelle e viste del database. PUNTO.
Scusa se è passata quasi una settimana, ma mi hanno impegnato su un altro
fronte. Ho fatto un po' di prove col tuo sql. Avendo una versione vecchia di
SQL Server l'ho modificato in:
--creo un database su cui farò le mie prove
CREATE DATABASE MyDB
GO
--creo un login
EXEC sp_addlogin 'MyTest' ,'abc123'
GO
--vado nel db appena creato
USE MyDB
GO
--creo una tabella di prova
CREATE TABLE dbo.MyTable
(
 ID smallint not null,
 c1 varchar(20) not null
)
GO
--la popolo con un record
INSERT dbo.MyTable VALUES (1, 'aaa')
GO
--il login di prima lo rendo user del db
EXEC sp_grantdbaccess 'MyTest'
GO
--e membro del ruolo db_datawriter
EXEC sp_addrolemember db_datawriter, MyTest
GO
--e del ruolo db_datareader
EXEC sp_addrolemember db_datareader, MyTest
GO
E ho creato l'utente. Ho poi verificato la possibilità di fare INSERT,
UPDATE e DELETE da Query Analyzer e tutto funziona. Ho pure tentato, poi di
vedere se tutto era ok anche deselezionando db_datareader o db_datawriter e
il comportamento è sempre quello che mi aspetto.
Ora però torno al mio problema specifico, perchè evidentemente l'errore è
altrove:
io ho una routine VBA che da un DB Access crea una tebella collegata verso
un DB SQL Server usando la stringa di connessione ADO:
ODBC;DRIVER=SQL Server;SERVER=MyServer;APP=Microsoft Office
XP;WSID=MioNomePC;DATABASE=MyDB;Uid=MyTest;PWD=abc123;
Il link viene creato, ma se cerco di aprirlo succede che:
a) se mancano i diritti db_datareader, la tabella non si apre - GIUSTO
b) se ho i diritti solo db_datareader, apro solo in lettura - GIUSTO
c) se ho i diritti db_datawriter apro solo in lettura - SBAGLIATO!
quello che non capisco è il caso C!
Ad ogni modo ho provato, poi, a creare sul DB Access 3 Query:
INSERT INTO MyTable ( ID, c1 ) SELECT 34 AS Espr1, "ccc" AS Espr2 FROM
MyTable;
UPDATE MyTable SET MyTable.c1 = "fff" WHERE (((MyTable.ID)=34));
DELETE MyTable.ID, MyTable.c1 FROM MyTable WHERE (((MyTable.ID)=34));
e i risultati sono stati che:
a) L'INSERT funziona.
b) l'UPDATE mi da un errore "Per l'operazione è necessaria una query
aggiornabile. (3073)."
c) il DELETE da un errore "Impossibile eliminare dalle tabelle specificate.
(3086)."
[i codici li ho presi dall'help di Access]
stessi risultati se eseguo le stesse query da VBA:
CurrentDb.Execute ("INSERT INTO MyTable ( ID, c1 ) SELECT 34 AS Espr1,
""ccc"" AS Espr2 FROM MyTable;")
CurrentDb.Execute ("UPDATE MyTable SET MyTable.c1 = ""fff"" WHERE
(((MyTable.ID)=34));")
CurrentDb.Execute ("DELETE MyTable.ID, MyTable.c1 FROM MyTable WHERE
(((MyTable.ID)=34));")
Insomma, alla fine della fiera due operazioni su 3 non sono fattibili: c'è
qualcosa che non va con luso di access. Anche facendo il link a mano, dopo
aver creato un apposito file DSN il risultato non cambia.....


 (3086)."
OK, definisci una chiave primaria o un indice univoco sulla tabella.
Access, per impostazione predefinita, apre un cursore che č in grado di fare 
aggiornamenti SOLO se č in grado di individuare univocamente una riga in 
base ad un campo (pk o indice unique appunto). L'inserimento va a buon fine 
perchč non ha alcuna importanza individuare i record esistenti...


 perchè non ha alcuna importanza individuare i record esistenti...
Ho provato ed è così!!! un po' limitativo ma basta saperlo....
MI rimane una domanda [so che stai pensando che ho rotto ormai ;-) ]:
Perchè se io faccio il collegamento di una tabella da Access verso SQL
Server "a mano" (cioè definendo un file DSN e poi scegliendo tra le opzioni
di collegamento la tipologia ODBC con quel DSN) ottengo un link che mi
permette di alterare i dati nella tabella (intendo dire aprendo la tabella e
digitando qualcosa in una cella, non stramite VB o SQL), mentre non è così
se genero il link tramite VB ponendo nella sua proprietà .Connect la stessa
stringa? I diritti sono in entrambi i casi di tipo dbo.


 stringa? I diritti sono in entrambi i casi di tipo dbo.
Io ricreo la stringa di connessione odbc e riesco a modificare
tranquillamente le tabelle. Sei sicuro che dipenda da quello?
-- 
David Martin


Ritiro tutto: ho capito dov’è la magagna, anche se non ho capito bene perché
si comporta così….
La situazione è questa: ho definito 2 utenze di tipo DB Owner in maniera che
ognuno possa gestire per quanto gli compete l’aggiornamento di alcune
tabelle, dopodiché, tutti gli altri utenti, semplici DB Reader accederanno
alle tabella in lettura. Quello che non mi torna è perché una taballa creata
dal DB Owner A non possa essere modificata dal DB Owner B! Infatti se
collego dentro un DB Access le tabelle del SQL Server e le apro, su quelle
create da me faccio quello che mi pare, su quelle create dall’altro non
faccio nulla. Sto parlando sempre di andare a mano dentro una tabella e
digitare qualcosa in una determinata cella, le query sembrano funzionare….
