Utilizzo dei ruoli applicazione con progetti di Access e SQL Server 2000 Desktop Edition

Avanzate: Richiede competenze multiutente, interoperabilità e la codifica degli esperti.

In questo articolo si applica solo a un progetto di Microsoft Access (adp).


Per la versione di Microsoft Access 2000 di questo articolo, vedere
318816 .

Riepilogo

In questo articolo vengono illustrate le funzionalità, le limitazioni e le soluzioni alternative per l'utilizzo dei ruoli applicazione di Microsoft SQL Server in un progetto di Microsoft Access (ADP).

Ulteriori informazioni

In SQL Server, è possibile creare ruoli del database per semplificare l'amministrazione delle autorizzazioni in un database. Invece di concedere autorizzazioni individuali a ciascun utente separatamente, è possibile raggruppare gli utenti con le stesse esigenze di autorizzazione rendendoli membri del ruolo del database regolare stesso e quindi assegnando le autorizzazioni al ruolo del database stesso. A meno che non sia esplicitamente negata altrove un'autorizzazione specifica, gli utenti membri acquisirà le autorizzazioni consentite al ruolo del database.

Mentre i ruoli di database regolare sono molto utili nelle situazioni in cui si desidera che gli utenti possano eseguire le proprie query ad hoc o gli aggiornamenti in un database, non sono sempre appropriati. In alcuni casi, si consiglia agli utenti solo di determinate autorizzazioni quando utilizzano un'applicazione specifica e non si desidera essere in grado di visualizzare o modificare i dati di fuori dell'applicazione.

Un metodo che viene spesso utilizzato per aggirare questo è solo fornire le autorizzazioni necessarie per un account utente di SQL Server. Gli utenti effettivi che disponga delle autorizzazioni per connettersi a un database ma non di visualizzare o modificare i dati. Dopo che un utente si connette al database utilizzando singoli account utente, il ADP potrebbe quindi a livello di codice riconnettersi utilizzando le credenziali dell'account utente che dispone delle autorizzazioni. Ciò può essere efficace, non consente di distinguere tra gli utenti del database o per determinare quale utente ha eseguito un'azione particolare.

I ruoli applicazione sono progettati per aggirare questa limitazione. I ruoli applicazione, a differenza dei ruoli di database regolare, non hanno membri stessi. Al contrario, gli utenti accedere a un SQL Server e connettersi a un database utilizzando le proprie credenziali. A questo punto, il contesto di protezione di un ruolo applicazione applicabile a livello di codice per una connessione esistente utilizzando la procedura sp_setapprole archiviati. In SQL Server, singoli utenti sono ancora distinti, ma le autorizzazioni che sono disponibili all'interno di un particolare tipo di connessione sono limitate alle autorizzazioni del ruolo applicazione. Le singole autorizzazioni dell'utente, se inferiore o superiore, non sono più considerate.

Creazione di un ruolo applicazione

Progetti di Microsoft Access non dispongono di alcuno strumento di progettazione visiva per la creazione di oggetti di protezione di SQL Server quali i ruoli applicazione. Microsoft consiglia di utilizzare gli strumenti client forniti con la versione regolare di SQL Server o Microsoft Office XP Developer per la creazione del ruolo di applicazione e assegnazione di autorizzazioni. È tuttavia possibile creare il ruolo di applicazione e concedergli le autorizzazioni necessarie a livello di codice utilizzando Transact-SQL (T-SQL) da un file ADP. Sebbene una trattazione completa della protezione di SQL Server non rientra nell'ambito del presente articolo, ulteriore informazioni sono reperibili nella Documentazione in linea di SQL Server la procedura seguente mostra come creare un ruolo applicazione e concedere al nuovo ruolo Selezionare autorizzazioni su una tabella a livello di codice:
  1. Avviare Access.
  2. Aprire il progetto di Access di esempio Northwind.
  3. Nella finestra del Database, fare clic su moduli in oggettie quindi fare clic su Nuovo per aprire un nuovo modulo nell'ambiente di Visual Basic.

    Nota: In Access 2007, fare clic su modulo nel gruppo della scheda Crea .
  4. Digitare o incollare il codice seguente nel nuovo modulo:
    Public Function AddNewAppRole(RoleName As String, PW As String) As BooleanOn Error GoTo EH:
    If CurrentProject.IsConnected Then
    Dim sTSQL As String
    'Create the command
    sTSQL = "EXEC sp_addapprole '" & RoleName & "','" & PW & "'"
    'Send the command
    Application.CurrentProject.Connection.Execute sTSQL
    AddNewAppRole = True
    Else
    AddNewAppRole = False
    End If
    Exit Function
    EH:
    MsgBox Err.Number & ": " & Err.Description, vbCritical
    AddNewAppRole = False
    End Function

  5. Salvare il modulo e quindi uscire dall'ambiente di Visual Basic.
  6. Creare una copia della tabella Customers e quindi salvarlo come tNewTable. A tale scopo, attenersi alla seguente procedura:
    1. Nella finestra del Database, destro della tabella Customers e scegliere Salva con nome dal menu di scelta rapida.

      Nota: In Access 2007, fare clic sulla tabella clienti nel riquadro di spostamento, fare clic sul Pulsante Microsoft Office, scegliere Salva con nomee quindi fare clic su Salva oggetto con nome.
    2. Nella finestra di dialogo Salva con nome digitare tNewTable nella tabella 'Clienti' alla casella e quindi fare clic su OK.
  7. Nella finestra del Database selezionare maschere nell'elenco oggetti, fare clic su Nuovoe quindi fare clic su OK per aprire una nuova maschera in visualizzazione struttura.

    Nota: In Access 2007, fare clic su Struttura nel gruppo maschere della scheda Crea .
  8. Aggiungere un pulsante di comando per il nuovo modulo.
  9. Impostare la proprietà OnClick del pulsante di comando nuovo alla routine evento seguente:
    On Error GoTo EH:'Code only works if ADP is connected.
    If CurrentProject.IsConnected Then
    Dim bNewAppRole As Boolean, strTSQL As String
    Dim strRoleName As String, strPW As String
    strRoleName = "AppRoleName"
    strPW = "Password"
    'Call function to create app role.
    bNewAppRole = AddNewAppRole(strRoleName, strPW)
    'Test to see if it failed.
    If bNewAppRole = False Then
    Exit Sub
    End If
    MsgBox "New Application role '" & strRoleName & "' created", vbInformation
    'Create command to grant permissions.
    strTSQL = "Grant Select on tNewTable to " & strRoleName
    'Send the command.
    Application.CurrentProject.Connection.Execute strTSQL
    MsgBox "Select permissions granted on tNewTable for " & strRoleName
    Else
    MsgBox "ADP must be connected to SQL Server"
    End If
    Exit Sub
    EH:
    MsgBox Err.Number & ": " & Err.Description, vbCritical

  10. Chiudere l'ambiente di Visual Basic per tornare al modulo.
  11. Salvare il modulo e quindi passare alla visualizzazione Maschera.
  12. Fare clic sul pulsante di comando per eseguire il codice sottostante.

    Si noti che viene visualizzato due finestre di messaggio per indicare un esito positivo. Verrà visualizzato una volta viene creato il ruolo di applicazione e il secondo dopo le nuove autorizzazioni di ruolo a tNewTable vengono concesse.

Implementazione del ruolo applicazione

La complicazione principale quando si utilizzano i ruoli applicazione nei progetti di Access è che Access utilizza tre connessioni a SQL Server per gestire le varie attività. In teoria, per applicare un ruolo applicazione per l'intero progetto, è necessario eseguire sp_setapprole nel contesto di tutte e tre le connessioni. Gli oggetti gestiti da ogni connessione sono i seguenti:

  1. Utilizzato per determinare quali oggetti vengono visualizzati nella finestra del Database e per operazioni di amministrazione di database esterni.

    Utilizzato per l'apertura di tabelle, viste, stored procedure, funzioni e le origini record per maschere e i sottoreport (ma non per il report principale).

    Utilizzato per ottenere le origini record per le caselle di riepilogo, caselle combinate e report.
  2. Utilizzato per l'apertura di tabelle, viste, stored procedure, funzioni e le origini record per maschere e i sottoreport (ma non per il report principale).

    Utilizzato per ottenere le origini record per le caselle di riepilogo, caselle combinate e report.
  3. Utilizzato per ottenere le origini record per le caselle di riepilogo, caselle combinate e report.

Sebbene le connessioni #2 e #3 abbastanza facilmente accessibile, non è disponibile per l'esecuzione della stored procedure nel contesto di connessione #1 alcun metodo. Fortunatamente, la connessione è meno importante dei tre e facilmente risolto creando un'interfaccia utente personalizzata (ad esempio, una maschera pannello comandi) per la gestione degli oggetti di database invece di basarsi sulla finestra del Database incorporata.

La procedura seguente utilizza il progetto di Access di esempio Northwind per illustrare come applicare un ruolo applicazione con connessioni #2 e #3:

  1. Nella finestra del Database selezionare maschere nell'elenco oggetti, fare clic su Nuovoe quindi fare clic su OK per aprire una nuova maschera in visualizzazione struttura.

    Nota: In Access 2007, fare clic su Struttura nel gruppo maschere della scheda Crea .
  2. Aggiungere una casella di riepilogo al form appena creato e quindi impostare la proprietà Name della casella di riepilogo per lst_AppRole.
  3. Aggiungere un pulsante di comando alla maschera.
  4. Impostare la proprietà OnClick del pulsante di comando nuovo alla routine evento seguente:
    On Error GoTo EH    'This avoids a message that no records were returned.
    DoCmd.SetWarnings False
    Dim TSQL
    TSQL = "EXEC sp_setapprole 'AppRoleName', {Encrypt N 'Password'}, 'odbc'"
    'This sets the app role on Connection #2.
    Application.CurrentProject.Connection.Execute TSQL
    'This sets the app role on Connection #3.
    lst_approle.RowSource = TSQL
    lst_approle.Requery
    DoCmd.SetWarnings True
    MsgBox "The application Role is now in effect.", vbInformation
    Exit Sub
    EH:
    MsgBox Err.Number & ": " & Err.Description, vbCritical

  5. Chiudere l'ambiente di Visual Basic per tornare al modulo.
  6. Salvare il modulo e quindi passare allavisualizzazione Maschera.
  7. Fare clic sul pulsante di comando per eseguire il codice sottostante.

    Si noti che viene visualizzato un messaggio che indica l'esito positivo.
  8. Nella finestra del Database scegliere tabelle dall'elenco oggettie quindi aprire la tabella tNewTable .

    Nota: In Access 2007, fare doppio clic sulla tabella tNewTable nel riquadro di spostamento.
  9. Modificare un record e si tenta di salvare le modifiche.
Si noti che quando si tenta di salvare le modifiche, viene visualizzato un messaggio di errore relativo a non disporre di autorizzazioni sufficienti. Ciò si verifica perché è assegnato il nuovo ruolo di applicazione Selezionare autorizzazioni ma non nella tabella tNewTable
Autorizzazione di aggiornamento .

Per impostazione predefinita, Access visualizza solo gli oggetti nella finestra del Database per cui l'utente ha almeno Select o le autorizzazioni di esecuzione. #1 di connessione utilizzato per determinare quali oggetti utente disponga delle autorizzazioni per. Dopo aver applicato il ruolo di applicazione per le connessioni #2 e #3, la finestra del Database viene comunque gli stessi oggetti che non è stato modificato, anche se l'utente potrebbe non disporre delle autorizzazioni per tutti gli oggetti, o che disponga delle autorizzazioni per più oggetti che non vengono visualizzati. Ciò può causare un comportamento imprevisto quando si utilizza la finestra del Database.

Ad esempio, quando si apre la tabella tNewTable, "sembra" che l'utente dispone delle autorizzazioni per modificare e inserire record. L'icona Inserisci di nuovo record nella parte inferiore della tabella è attivata e l'utente è in grado di inserire un record in modalità di modifica. Non è presente alcuna traccia visiva per indicare, in caso contrario, fino a quando si tenta di eseguire il commit della modifica o inserimento, che dà come risultato un messaggio di errore. Accesso ritiene di che disporre delle autorizzazioni quando in realtà non.

La soluzione più efficace consiste nel fornire un'interfaccia personalizzata per l'utente e di non fare affidamento sulla finestra del Database. Utilizzando un'interfaccia utente di tipo di pannello comandi, è possibile controllare esattamente gli oggetti che l'utente ha accesso a.

Altre limitazioni e considerazioni sulla protezione

Subforms non funziona

A differenza di altri oggetti di database, Access non utilizza sempre la stessa connessione per recuperare l'origine dati di una sottomaschera. Spesso, ma non sempre, Access crea una nuova connessione a SQL Server per gestire il recordset sottomaschera o per recuperare i dati del campo collegamento che connette la sottomaschera alla maschera principale. Perché questa nuova connessione non ha il ruolo di applicazione, se non si dispongono di autorizzazioni esplicite per l'oggetto di database venga generato un errore di autorizzazioni. Sfortunatamente, ciò significa che non è affidabile per l'utilizzo di sottomaschere associate quando vengono applicati i ruoli applicazione. Valido solo per risolvere il problema è completamente è stata annullata sottomaschere, con la manipolazione dei dati a livello di codice gestito. Si tratta di limitazione più grave quando si utilizzano i ruoli applicazione in Access.

Report non funziona

Quando si dispone di un oggetto, ad esempio una tabella o un nome di visualizzazione è elencato come origine record per un report o un sottoreport, controlli di accesso per verificare se l'oggetto è elencata nella finestra del Database prima di recuperare i dati da SQL Server. Poiché la finestra del Database utilizza una connessione che non ha il ruolo di applicazione, viene generato un errore se si dispone delle autorizzazioni esplicite per l'origine dati sottostante.

Per risolvere questo problema, utilizzare sempre le istruzioni Transact-SQL come origine record per maschere e report. Ad esempio, utilizzare "Seleziona * da ViewName" anziché "ViewName" o "Exec StoredProcedureName" anziché solo "StoredProcedureName". In questo modo, Access passa direttamente le istruzioni Transact-SQL di SQL Server e recupera i dati in base alle autorizzazioni del ruolo applicazione.

Il ruolo del Database pubblico

Un ruolo applicazione acquisisce le autorizzazioni del ruolo di database Public. Per impostazione predefinita in NorthwindCS, al ruolo Public dispone di autorizzazioni complete per la maggior parte degli oggetti. Pertanto, un ruolo applicazione è generalmente inefficace. Quando la tabella tNewTable è stato creato nella sezione "Creazione di un ruolo applicazione", il ruolo Public non è stata concessa l'autorizzazione per la tabella e si è visto in un secondo momento gli effetti del contesto di protezione del ruolo applicazione su tale tabella. Tuttavia, altre tabelle non vengano visualizzate eventuali differenze in corrispondenza del ruolo applicazione perché il ruolo Public disponga delle autorizzazioni per tali oggetti.

Protezione VBA

Poiché la password per il ruolo applicazione è incorporata nell'applicazione da cui viene chiamato, un utente esperto sarebbe possibile leggere il nome del ruolo applicazione e la password dal codice sorgente e quindi utilizzare tali informazioni per l'accesso a SQL Server da un'altra applicazione. Pertanto, è consigliabile compilare il ADP in un file ADE in modo che il codice sorgente non è visualizzabile. Come minimo, applicare una password per il progetto VBA.

Riferimenti

Per ulteriori informazioni su una versione di Microsoft Access 2000 di questo articolo, fare clic sul numero dell'articolo per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:
318816 ACC2000: utilizzo di ruoli applicazione con progetti di Access e SQL Server 2000 Desktop Engine (MSDE 2000)
Per ulteriori informazioni sulle autorizzazioni, vedere la Documentazione in linea di SQL Server. La Documentazione in linea di SQL Server è disponibile il seguente sito Web Microsoft:
http://www.microsoft.com/sql/techinfo/productdoc/2000/default.asp
Proprietà

ID articolo: 308312 - Ultima revisione: 30 gen 2017 - Revisione: 1

Feedback