Newsgroup: it.comp.appl.access
Titolo: ADP (XP) + SQL Express + Vista + VIEW_METADATA

Stavo cercando modificare l'origine dati di una form da
SELECT * FROM Tabella WHERE Campo = Valore ORDER BY Campo1, Campo2, Campo3
ad una vista come la seguente:
CREATE VIEW [dbo].[qryAppuntamenti]
WITH VIEW_METADATA
AS
SELECT     TOP (100) PERCENT
[....elenco dei campi al posto dell'aterisco....]
FROM         dbo.Tabella
WHERE     (Campo >= Valore)
ORDER BY Campo1, Campo2, Campo3
L'intento era quello di togliere autorizzazioni (al gruppo public) esplicite 
alla Tabella ed impostarle invece alla vista.
Creata la query ho infatti impostato le autorizzazioni (al gruppo public) 
SELECT, INSERT, UPDATE e DELETE alla vista ed ho tolto le stesse alla Tabella.
Dopo avere quindi modificato l'origine dati della form, ho provato ad aprirla 
ma mi dice che gli manca l'autorizzazione SELECT.
Insomma, sembra che le autorizzazioni non vengano prese dalla query ma dalla 
tabella.
Idee?
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution


Nessuna. A rigor di logica mi sembra che non faccia una piega. Tu utente 
"VIEW" ti presenti al db e gli chiedi di leggere una tabella per cui non 
  sono concesse autorizzazioni. Al che, come si suol dire, il db 
risponde "picche". E' il minimo che deve fare.
--
ac

 risponde "picche". E' il minimo che deve fare.
Non sono molto d'accordo, anche in base a quanto ho letto proprio stamattina 
sul testo "SQL: Access to SQL Server" degli autori Harkins e Reid.
Cito testualmente un paragrafo nel quale si discute proprio la creazione 
di una form basata su una vista per fare l'inserimento dei dati: "By default, 
ADO and OLEDB will try to insert the data to the base table on which the 
view is based. This is because ADO queries certain information about the 
data when it is retrieved. By default, SQL Server tells ADO what the base 
object is, using the table as the base. Of course, the user does not have 
permission to work with the table, and so the insert fails. In fact, it's 
impossible to even attempt the insert because the form will not permit you 
to add data. By changing the option [n.d.r.: Update using view rules] using 
the Properties dialog box, ADO and OLE DB will use SQL statements that refer 
to the view rather than the base table for the update. Our user has permission 
to insert via the view, and so all is well."
Selezionando la proprietą cui si fa riferimento nel suddetto paragrafo, viene 
aggiunto nel codice SQL di creazione della vista, l'attributo WITH VIEW_METADATA.
Ti posso anche dire che ho provato la stessa cosa ma con SQL 2000 ed in questo 
caso funziona proprio nella maniera che ho descritto io e che ho letto sul 
volume da cui ho preso il trafiletto.
Evidentemente SQL 2000 e SQL 2005 si comportano diversamente riguardo a questo 
attributo WITH VIEW_METADATA.


A rafforzare la mia tesi posto anche il link ad un articolo di Mike Gunderloy 
che spiega proprio l'utilizzo dell'attributo VIEW_METADATA per ottenere un 
livello di sicurezza maggiore in maniera semplice.
http://redmondmag.com/columns/article.asp?EditorialsID=389


 Cito testualmente un paragrafo nel quale si discute proprio la creazione
CUT
Non concordo.
Il testo che citi dice che "tramite la vista l'utente riuscirà ad aggiornare 
la tabella anche se non ha permessi sulla tabella" ma il problema è 
analizzare questa vista la quale potrebbe contenere istruzioni per accedere 
alla tabella con autorizzazioni diverse dall'utente chiamante (una sorta di 
"WITH OWNER ACCESS OPTION" degli mdb)
Davide
-- 
www.gestionedati.com
 

 "WITH OWNER ACCESS OPTION" degli mdb)
La vista è la seguente:
CREATE VIEW [dbo].[qryAppuntamenti]
WITH VIEW_METADATA
AS
SELECT TOP (100) PERCENT *
FROM dbo.tblAppuntamenti
ORDER BY DataPrenotazione DESC, DataArrivo DESC, OraArrivo DESC
In ogni caso, approfitto del tuo post per suggerire a te ed a tutti quanti 
di leggere anche le risposte di Giorgio Rancati al mio post identico su microsoft.public.it.office.access.
Giorgio sostiene la mia tesi e concorda nel fatto che la vista in questione 
dovrebbe essere aggiornabile.
Per il momento non sono ancora arrivato ad una conclusione, ma sembra che 
il problema sia di Access, visto che con il SSMS Express funziona tutto proprio 
come mi sarei aspettato.
Sottolineo anche che con SQL 2000 funziona tutto proprio come dovrebbe, cioé 
l'attributo VIEW_METADATA permette di utilizzare la view per fare tutte le 
operazioni per le quali non si hanno permessi diretti sulle tabelle, mentre 
la sua mancanza non permette di fare alcunché se non si hanno i permessi 
sulla tabella di base.
Anche sui BOL di SQL 2005 è riportato questo stesso funzionamento per l'attributo 
in questione, perciò non si riesce a capire dove stia il problema.


"PBsoft" <in...@REMOVEpbsoft.it> ha scritto nel messaggio

Se avrò l'opportunità di fare prove in merito ti farò sapere.
Ciao
-- 
www.gestionedati.com