Newsgroup: it.comp.lang.visual-basic
Titolo: VB, SQL Server, Sicurezza e ADO

Abbiamo un grave problema. La situazione è questa.
Abbiamo un'applicazione VB6 che utilizza per gestire una base di dati,
l'accesso tramite ADO.
La base di dati è su un server remoto che utilizza SQL Server come
DBMS.
Gli aggiornamenti dei dati vengono fatti utilizzando la tecnica Batch,
quindi effettuando delle modifiche al database (INSERT, UPDATE, DELETE
o con istruzioni SQL embedded oppure con la chiamata di stored
procedure) su un recordset sconnesso e poi aggiornando il database
remoto con UpdateBatch.
Il tipo di Cursore che abbiamo utilizzato è adDynamic o adKeyset, il
tipo di Lock è adLockBaychOptimistic.
Per questioni di sicurezza il database è visibile dagli utenti
dell'applicazione solo tramite delle viste sulle tabelle fisiche.
Tutte le tabelle hanno come propretario dbo, mentre le viste hanno
permessi di accesso diversi a secondo del gruppo di utenti che vi
accedono (studenti, docenti, dipendenti, ecc.).
Il problema è che quando viene effettuato l'UpdateBatch viene generato
un errore da SQL Server di violazione della sicurezza.
Viene negato l'accesso perché SQL Server vede non l'accesso  alla
vista ma alla tabella su cui la vista è basata, la quale tabella
impedisce l'accesso a chiunque non sia dbo.
Oggi è il secondo giorno che ci stiamo combattendo sopra il risultato
è sempre "Access denied".
Il sospetto è che sia un baco di ADO, dato che, facendo lo SQL Trace
si vede che in corrispondenza dell'istruzione ADO UpdateBatch viene
generata ad es. una INSERT sulla tabella originaria specificando che
owner=dbo e generando dunque un errore, non tenendo conto che invece
l'inserimento dovrebbe essere permesso dato che si sta accedendo
tramite la vista correlata i cui permessi sono stati attivati per
l'utente in questione.
Qualcuno sa come si possa aggirare il problema non rinunciando ad ADO
e alla tecnica Batch?
Stefano & Stefano.

Sei sicuro che il problema non risieda semplicemente nel fatto che l'owner delle viste non sia dbo?
Se non ricordo male l'accesso alle tabelle da parte della vista avviene tramite l'owner.
Se provi ad inserire in una vista da Query Analizer (Sql Server) loggandoti come non dbo riesci ad inserire record?
Antonio Donatiello

 come non dbo riesci ad inserire record?
sì funziona
Stefano & Stefano

 tipo di Lock è adLockBaychOptimistic.
Non sono un "espertone", ma credo che per utilizzare recordset dissociati e
il lock adLockBaychOptimistic sia obbligatorio avere il cursore adUseClient,
che supporta solo adOpenStatic ed esclude l'uso dei tipi adDynamic o
adKeyset (che vorrebbero adUseServer).
Se tuttavia si usano lo stesso questi ultimi, viene in ogni caso generato un
cursore statico, senza però provocare un errore ADO!
Non saprei dire quanto questo possa contribuire ai vostri problemi, forse
nulla.
PS
Se ho toppato, abbiate pietà!

>adKeyset (che vorrebbero adUseServer).
Puoi avere adLockBatchOptimistic inisieme a adUseServer. L'ho appena usato con Sql Server e funziona.
Antonio Donatiello

Chiedo scusa se insisto, ma non capisco concettualmente come possa
funzionare, visto che l'aggiornamente batch ottimistico implica per sua
stessa definizione un recordset sconnesso e quindi un cursore lato client,
che a sua volta può essere solo statico. Se il cursore non fosse statico le
modifiche si verificherebbero immediatamente al cambio del record corrente,
no? (infatti per ADO non è necessario il metodo Update). Quindi si potrebbe
credere che abbia funzionato il batch ottimistico quando invece i record
erano già stati aggiornati singolarmente, a meno che non li si controlli
prima del comando di aggiornamento batch! Come hai verificato che in realtà
non sia stato generato un cursore statico lato
client, visto che ADO non ti avverte, ovvero non dà errore? La lettura della
proprietà CursorType dà il valore realmente generato o solo quello
impostato? Hai controllato forse se il client vede subito le modifiche fatte
da altri client (come dovrebbe accadere con un cursore dinamico lato
server)?
Ti sarei grato se mi chiarissi le idee, grazie.

>Ti sarei grato se mi chiarissi le idee, grazie.
Ti riferivi a me, giusto?
Antonio Donatiello

Il cursore lato cliente non deve essere statico. Cio' vorrebbe dire che non
posso fare update? Assurdo. Se >accesi a database Access il cursore e' di
tipo client sempre!
Qui invece non sarei d'accordo: il cursore lato client può essere solo
statico, non potendo vedere in tempo reale le modifiche degli altri client.
Questo lo puoi leggere anche nella doc. dell'SDK, alla voce "CursorType
Property":
"Only a setting of adUseStatic is supported if the CursorLocation property
is set to adUseClient."
La possibilità di fare Update dipende dal LockType!
Ti ringrazio per la disponibilità.
Ciao.
--
Rogis
* ANTI-SPAM:
Rimuovi "ABC" dall'indirizzo per rispondermi
Remove "ABC" from my address to reply.