SQL Server - credenziali di accesso alle tabelle: non ho capito una fava....
P@olo
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/
David Martin
> 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)
E non è giusto?
Scusa, hai impostato tu l'utente come uno che può solo scrivere e non
leggere, quindi non può aprire la tabella...
> 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?
Nella singola tabella non vedi nulla, perché le autorizzazioni sono
impostate a livello di Ruolo.
--
David Martin
Luca Bianchi
> 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)
E' giusto così perchè se l'utente può soltanto modificare i dati non gli hai
detto che può anche leggerli.
> 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?
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/
P@olo
scritto:
> > 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)
>
> E' giusto così perchè se l'utente può soltanto modificare i dati non gli
hai
> detto che può anche leggerli.
Giusto....
Però se aggiungo anche db_datareader, ottengo l'accesso in lettura, ma non
in scrittura, sia che vada a modificare il singolo campo "da tastiera" sia
che esegua query di DELETE!!!
L'accodamento invece me lo fa fare....
> > 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?
>
> 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
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!
Luca Bianchi
> in scrittura,
"se aggiungi anche" lo interpreto come "l'utente è sia db_datareader che
db_datawriter". Allora significa che può fare SELECT, INSERT, UPDATE e
DELETE su tutte le tabelle e viste del database. PUNTO.
> sia che vada a modificare il singolo campo "da tastiera" sia
> che esegua query di DELETE!!!
>
> L'accodamento invece me lo fa fare....
Ti fa fare tutto, segui questo esempio
=================================
USE master
GO
--creo un database su cui farò le mie prove
CREATE DATABASE MyDB
GO
--creo un login
CREATE LOGIN MyTest WITH PASSWORD = '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
CREATE USER MyTest FOR LOGIN 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
--assumo l'identità dell'utente creato (equivale a fare logon con questo
account)
EXECUTE AS USER = 'MyTest'
GO
--come vedi è in grado di inserire un record
INSERT dbo.MyTable VALUES (2, 'bbb')
GO
--di fare aggiornamenti
UPDATE dbo.MyTable
SET c1 = 'xyz'
WHERE ID = 1
GO
--e cancellazioni
DELETE dbo.MyTable
WHERE ID = 1
GO
--visto che è un datareader esegue anche delle select
SELECT * FROM dbo.MyTable
GO
--riassumo la mia identità
REVERT
=================================
Verifica quello che hai fatto con l'esempio che ti ho riportato e vedrai che
funziona... ;-)
> 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!
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...
P@olo
scritto:
> > Però se aggiungo anche db_datareader, ottengo l'accesso in lettura, ma
non
> > in scrittura,
>
> "se aggiungi anche" lo interpreto come "l'utente è sia db_datareader che
> db_datawriter". Allora significa che può fare SELECT, INSERT, UPDATE e
> 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.....
Luca Bianchi
> 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)."
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...
P@olo
scritto:
> > 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)."
>
> OK, definisci una chiave primaria o un indice univoco sulla tabella.
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
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.
David Martin
> 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.
Io ricreo la stringa di connessione odbc e riesco a modificare
tranquillamente le tabelle. Sei sicuro che dipenda da quello?
--
David Martin
P@olo
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….