Newsgroup: it.comp.appl.access
Titolo: ADP + form + stored procedure + update

Sto cercando di risolvere un problema con un ADP (Access 2003) con dietro 
SQL 2005.
Ho basato la form frmAnagrafica sulla stored procedure spAnagrafiche, definita 
come segue:
===============================
ALTER PROCEDURE [dbo].[spAnagrafiche]
	@IDAnag int = NULL
AS
BEGIN
	SET NOCOUNT ON
	SELECT @IDAnag = ISNULL(@IDAnag, -1)
	SELECT tblAnagrafiche.*
	FROM tblAnagrafiche
	WHERE @IDAnag = CASE WHEN @IDAnag = -1 THEN -1 ELSE tblAnagrafiche.IDAnagrafica 
END
	ORDER BY tblAnagrafiche.NomeVis
END
===============================
A questo punto, risulta banale filtrare la form semplicemente variando la 
proprietà InputParameters.
Per motivi di sicurezza, ad un normale utente non ho dato alcuna autorizzazione 
sulla tabella tblAnagrafiche, mentre gli ho dato l'autorizzazione di EXECUTE 
sulla stored procedure spAnagrafiche.
Nessun problema nell'apertura della form, nella consultazione dei dati e 
nel filtraggio dei record.
Se, però, cerco di fare un qualsiasi aggiornamento, ottengo il famigerato 
warning "Recordset non aggiornabile" nella barra di stato di Access.
Cercando approfonditamente su internet ho trovato il seguente articolo, che 
fornisce anche una soluzione: 
http://support.microsoft.com/default.aspx?scid=kb;en-us;248095&Product=acc2000
Purtroppo la soluzione proposta non è applicabile al mio caso, perché richiede 
almeno l'autorizzazione SELECT sulla tabella da aggiornare.
Cercando ancora meglio, ho trovato il seguente post, nel quale si spiega 
precisamente che non c'è trippa per gatti: il result set di una stored procedure 
non è mai aggiornabile: 
http://groups.google.com/group/microsoft.public.access.adp.sqlserver/browse_thread/thread/93cae277a93c5440/6240ee0e1aca4a4f?lnk=st&q=adp+form+bound+stored+procedure+update+problem&rnum=1#6240ee0e1aca4a4f
Ora, fatte tutte queste considerazioni, la strada da intraprendere per mantenere 
le restrizioni sulla sicurezza che tanto desidero, sembra quella di creare 
delle viste con l'attributo WITH_VIEW_METADATA.
Peccato che le viste non possono accettare parametri; per non parlare poi 
della clausola di ordinamento che viene accettata come sintassi (obbligando 
comunque ad inserire un TOP 100 PERCENT) ma poi ignorata dal motore di database.
Avete quindi qualche soluzione da propormi?
Grazie.
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype:pbsoftsolution

 di creare delle viste con l'attributo WITH_VIEW_METADATA.
Scusa ma se vuoi impedire la select/insert/update/delete sulla tabella, come 
potrebbe aiutarti la vista ?
Ciao
-- 
Giorgio Rancati
[Office Access MVP] 

 tabella, come potrebbe aiutarti la vista ?
Capisco quello che vuoi dirmi.
Il mio è un tentativo di seguire una giusta rotta :-)
Diciamo che, con le query, volendo, posso nascondere all'utente la struttura 
del database.
E, comunque, posso tenerlo lontano dal manipolare le tabelle.


 E, comunque, posso tenerlo lontano dal manipolare le tabelle.
ok, allora crea la vista, concedi solo i permessi di 
Insert/Update/Delete/Select e usala nella stored procedure al posto della 
tabella
----
ALTER PROCEDURE [dbo].[spAnagrafiche]
@IDAnag int = NULL
AS
BEGIN
SET NOCOUNT ON
SELECT @IDAnag = ISNULL(@IDAnag, -1)
SELECT *
FROM uv_tblAnagrafiche
WHERE @IDAnag = CASE WHEN @IDAnag = -1 THEN -1 ELSE 
tblAnagrafiche.IDAnagrafica
END
ORDER BY NomeVis
END
----


 della tabella
Scusa ma quale sarebbe il vantaggio rispetto ad utilizzare direttamente una 
SP?
In questo caso da Access si vede comunque la query.
Oppure non ho capito a chi dovrei dare le autorizzazioni di S,I,U,D.


 In questo caso da Access si vede comunque la query.
era la prima domanda che ti ho fatto :-)
la vista può essere comoda se vuoi nascondere determinati campi della 
tabella, ed è quello che erroneamente ho capito dalla tua risposta.
Se non vuoi far vedere la vista credo ci sia poco da fare con Access.
L'alternativa sarebbe quella di eseguire le Update/Delete/Insert con altre 
Sp ma bisognerebbe lavorare con una maschera non associata, insomma un 
lavoraccio.
:-)


 lavoraccio.
E' proprio per evitare questo lavoraccio che poi sono passato ad utilizzare 
delle query.
Non è certo un problema che il cliente possa vedere il nome delle query, 
tanto se non gli fornisco almeno l'autorizzazione VIEW DEFINITION il clente 
non può fare altro che vedere quello che io voglio fargli vedere.
Alla bisogna, si potrebbe ricorrere anche all'uso degli ALIAS, ma non è il 
mio caso.
Grazie mille per questo confronto.
