Se dici di aver dato "permessi di sola lettura per lo schema A" immagino che hai eseguito il comando

GRANT SELECT ON SCHEMA::A TO utente

Se la tua esigenza è quella di dare esclusivamente il permesso di lettura su una tabella, ancorchè facente parte dello schema A, il comando da eseguire doveva essere

GRANT SELECT ON A.anagrafica TO utente

Ovvio che se lasci così le cose il tuo utente continuerà a leggere comunque tutte le tabelle dello schema A per effetto del permesso precedente; puoi rimuoverlo con il comando

REVOKE SELECT ON SCHEMA:A TO utente

Sul BOL trovi tutti gli approfondimenti necessari.

Bye

Ovviamente non è uguale... :-)
Quelli che hai citato sono ruoli a livello di database e andando con ordine il ruolo db_datareader conferisce all'utente che ne fa parte di fare select su tutte le tabelle e su tutte le viste del database (nel precedente post mi avevi detto di avergli dato SOLO permessi di lettura sullo schema A mentre gli hai dato permessi su tutto il database e quindi su tutti gli schema); il ruolo db_denydatawriter impedisce agli utenti che ne fanno parte di eseguire INSERT, UPDATE e DELETE sempre, ovviamente, su tutto il db (e per la proprietà transitiva su tutti gli schema del database). Non è necessario che l'utente appartenga a questo ruolo perchè già di suo non può apportare modifiche senza permessi espliciti (e non ne hai dati). Infine il ruolo public è il ruolo di default; non lo hai selezionato tu ma era già pre-impostato. Tutti gli utenti fanno implicitamente parte di questo ruolo e nessun utente può essere rimosso da public.
Quindi mi dispiace dirlo ma nulla di quello che hai fatto serve a quello che vuoi fare... :-)
Rimetti le cose a posto, esegui il comando GRANT come te l'ho scritto io o, in alternativa, nell'interfaccia dove hai assegnato i ruoli vai nella sezione Securables, seleziona l'oggetto di tuo interesse e assegnagli i permessi che vuoi. Come vedi si fa prima via T-SQL... :-)

symonx80 ha scritto:

Alla fine ho però messo in datareader l'utente.

Questo non è quello che avevi detto all'inizio. In questo modo l'utente può fare select su TUTTE le tabelle e su TUTTE le viste del database.

Il problema è che così l'utente non riesce a vedere le stored procedure del db.
Sono andato allora nelle proprietà dell'user per il db relativo e nella sezione SECURABLES vorrei impostare che l'utente può solo leggere le stored procedure.

"leggere" una stored procedure significa vederne il codice con cui sono state definite (permesso VIEW DEFINITION); più verosimilmente l'utente deve ESEGUIRE le stored procedure e allora il permesso diventa

GRANT EXECUTE ON nomesp TO utente

Il problema è che le stored procedure sono un centinaio e non riesco a selezionarle tutte insieme in una volta ma sono costretto a flaggarle una ad una.
Come posso evitare questo?

Facendo tesoro di quanto ti ho detto nel primo post, ovvero di assegnare i permessi non sul singolo oggetto, ma sullo schema, ovvero

GRANT EXECUTE ON SCHEMA::nomeschema TO utente

In questo modo il tuo utente sarà in grado di eseguire TUTTE le stored procedure attuali e future nello schema che vuoi (esempio dbo). Per fare la stessa attività dall'interfaccia grafica devi scegliere, in Securables, gli schema e su quello che ti interessa assegni il permesso EXECUTE (e/o SELECT e/o quello che vuoi)

Quale object_name hanno le stored procedur di un db?Esiste un elenco degli object_name di un db a cui fare riferimento?Non ho trovato nulla in rete di preciso...

Se hai cercato "quale object_name hanno le stored procedure" mi sarei meravigliato se avessi trovato qualcosa. L'object name è il nome che viene assegnato a ciascun oggetto. La tabella Pippo ha object name Pippo, la stored procedure Topolino ha object name Topolino. Pertanto si tratta di un attributo già noto; se invece vuoi conoscere TUTTI i nomi delle stored procedure, allora puoi interrogare la vista INFORMATION_SCHEMA.ROUTINES (contiene anche le udf) di cui trovi ampia documentazione sul BOL.

Bye