Al momento sei offline in attesa che la connessione Internet venga ristabilita

Come utilizzare i ruoli di applicazione con i progetti di Access e SQL Server 2000 Desktop Edition

Support for Office 2003 has ended

Microsoft ended support for Office 2003 on April 8, 2014. This change has affected your software updates and security options. Learn what this means for you and how to stay protected.

Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell’utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell’utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.

Clicca qui per visualizzare la versione originale in inglese dell’articolo: 308312
Avanzate: Richiede la codifica degli esperti, interoperabilità e competenze multiutente.

Il contenuto di questo articolo è applicabile solo ai progetti di Microsoft Access (adp).

Per la una versione di Microsoft Access 2000 di questo articolo, vedere 318816.
Sommario
In questo articolo vengono illustrate le funzionalità, le limitazioni e le soluzioni alternative per l'utilizzo dei ruoli di applicazione di Microsoft SQL Server in un progetto di Microsoft Access (ADP).
Informazioni
In SQL Server, è possibile creare ruoli del database per semplificare l'amministrazione delle autorizzazioni in un database. Invece di concedere autorizzazioni singole per ciascun utente separatamente, è possibile raggruppare gli utenti con le esigenze di autorizzazione stessa rendendoli membri del ruolo database regolare stesso e assegnando autorizzazioni al ruolo del database stesso. A meno che non un'autorizzazione specifica in modo esplicito viene negata in un' posizione, è possibile che utenti membri acquisirà le autorizzazioni concesse al ruolo del database.

Sebbene i ruoli di database regolare sono molto utili per situazioni in cui si desidera che gli utenti per poter eseguire le proprie query ad hoc o gli aggiornamenti per un database, non sono sempre appropriati. In alcuni casi, è consigliabile solo agli utenti alcune autorizzazioni quando si utilizza un'applicazione specifica e non si desidera poter visualizzare o modificare i dati all'esterno dell'applicazione.

Che viene spesso utilizzata per aggirare questo è possibile assegnare solo le autorizzazioni necessarie a un account utente di SQL Server. Gli utenti effettivi dispone di autorizzazioni di connessione a un database ma non di visualizzare o modificare i dati. Dopo che un utente si è connesso al database utilizzando l'account dell'utente singoli, il ADP potrebbe quindi a livello di programmazione riconnettere utilizzando le credenziali dell'account utente che dispone di autorizzazioni. Mentre questo può essere efficacia, non consente di distinguere tra gli utenti del database o di determinare quale utente ha eseguito un'azione particolare.

I ruoli applicazione sono progettati per ovviare a questa limitazione. I ruoli applicazione, a differenza dei ruoli di database regolare, non dispongono di membri stessi. Invece gli utenti di accedere a SQL Server e di connettersi a un database utilizzando le proprie credenziali. A questo punto, il contesto di protezione di un ruolo applicazione può essere applicato a livello di codice per una connessione esistente utilizzando la procedura sp_setapprole memorizzati. In SQL Server, singoli utenti sono ancora distinti, ma le autorizzazioni disponibili all'interno di una particolare connessione sono limitati alle autorizzazioni del ruolo applicazione. L'utente di singola autorizzazioni, se minore o versione successiva, non vengono considerati.

Creazione di un ruolo applicazione

Microsoft Access progetti non dispongono di qualsiasi strumenti di progettazione visiva per creare oggetti di protezione di SQL Server, ad esempio i ruoli applicazione. Microsoft consiglia di utilizzare gli strumenti client inclusi nella versione standard di SQL Server o Microsoft Office XP Developer per creare il ruolo di applicazione e l'assegnazione di autorizzazioni. Tuttavia, è comunque possibile creare il ruolo di applicazione e concedergli le autorizzazioni necessarie a livello di programmazione utilizzando a Transact-SQL (T-SQL) da un file ADP. Anche se una descrizione completa di SQL Server Security è esternamente all'ambito di questo articolo, ulteriore informazioni sono reperibili nella Documentazione in linea di SQL Server la seguente procedura illustrato come creare un ruolo applicazione e concedere autorizzazioni SELECT su una tabella del nuovo ruolo a livello di programmazione:
  1. Avviare Access.
  2. Aprire il progetto di Access di esempio Northwind.
  3. Nella finestra del database scegliere moduli dall'elenco oggetti , quindi Nuovo per aprire un nuovo modulo nell'ambiente di Visual Basic.

    Nota In Access 2007, scegliere il modulo nel gruppo della scheda Crea .
  4. Digitare o incollare il codice riportato di seguito nel nuovo modulo:
    Public Function AddNewAppRole(RoleName As String, PW As String) As BooleanOn Error GoTo EH:If CurrentProject.IsConnected ThenDim sTSQL As String    'Create the commandsTSQL = "EXEC sp_addapprole '" & RoleName & "','" & PW & "'"    'Send the commandApplication.CurrentProject.Connection.Execute sTSQLAddNewAppRole = TrueElseAddNewAppRole = FalseEnd IfExit FunctionEH:MsgBox Err.Number & ": " & Err.Description, vbCriticalAddNewAppRole = FalseEnd Function					
  5. Salvare il modulo e uscire dall'ambiente di Visual Basic.
  6. Creare una copia della tabella Customers e quindi salvarlo come tNewTable . Per effettuare questa operazione, attenersi alla seguente procedura:
    1. Nella finestra del database, fare clic con il pulsante destro del mouse sulla tabella clienti e scegliere Salva 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 nome e quindi scegliere Salva oggetto con nome .
    2. Nella casella finestra di dialogo digitare tNewTable nella tabella 'Clienti' per casella e quindi fare clic su OK .
  7. Nella finestra del database scegliere maschere dall'elenco oggetti fare clic su Nuovo e quindi fare clic su OK per aprire una nuova maschera in visualizzazione struttura.

    Nota In Access 2007, fare clic su Struttura nel gruppo Form nella scheda Crea .
  8. Aggiungere un pulsante di comando nuovo form.
  9. Impostare la proprietà di OnClick del pulsante di comando nuovo sulla routine evento riportata di seguito:
    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 " & strRoleNameElseMsgBox "ADP must be connected to SQL Server"End IfExit SubEH:MsgBox Err.Number & ": " & Err.Description, vbCritical					
  10. Chiudere l'ambiente Visual Basic per tornare al modulo.
  11. Salvare il modulo e quindi passare il modulo per la visualizzazione Maschera .
  12. Fare clic sul pulsante comando per eseguire il codice sottostante.

    Si noti che viene visualizzato due finestre di messaggio per indicare l'esito positivo. Verrà visualizzato una volta viene creato il ruolo di applicazione e il secondo uno dopo i nuovo autorizzazioni di ruolo per tNewTable vengano concesse.

Implementare il ruolo di applicazione

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

  1. Utilizzato per determinare quali oggetti vengono visualizzati nel database di finestra e per attività amministrative 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 stesso).

    Utilizzato per ottenere le origini record per caselle combinate, caselle di riepilogo 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 stesso).

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

Anche se è possibile accedere abbastanza facilmente connessioni 2 e 3, non disponibile alcun metodo per l'esecuzione della stored procedure nel contesto di connessione # 1. Fortunatamente, la connessione è meno importante dei tre e facilmente risolto creando un'interfaccia utente (ad esempio, un modulo di tipo di pannello comandi) per la gestione degli oggetti di database invece di utilizzare nella finestra del database incorporata personalizzata.

I seguenti passaggi utilizzato il progetto di Access di esempio Northwind per illustrare come applicare un ruolo applicazione con le connessioni 2 e 3:

  1. Nella finestra del database scegliere maschere dall'elenco oggetti fare clic su Nuovo e quindi fare clic su OK per aprire una nuova maschera in visualizzazione struttura.

    Nota In Access 2007, fare clic su Struttura nel gruppo Form nella scheda Crea .
  2. Aggiungere una casella di riepilogo al form appena creato e quindi impostare la proprietà Name di casella di riepilogo per lst_AppRole .
  3. Aggiungere un pulsante di comando alla maschera.
  4. Impostare la proprietà di OnClick del pulsante di comando nuovo sulla routine evento riportata di seguito:
    On Error GoTo EH    'This avoids a message that no records were returned.DoCmd.SetWarnings FalseDim TSQLTSQL = "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 = TSQLlst_approle.RequeryDoCmd.SetWarnings TrueMsgBox "The application Role is now in effect.", vbInformationExit SubEH:MsgBox Err.Number & ": " & Err.Description, vbCritical					
  5. Chiudere l'ambiente Visual Basic per tornare al modulo.
  6. Salvare il modulo e quindi passare il modulo per la visualizzazione Maschera .
  7. Fare clic sul pulsante comando per eseguire il codice sottostante.

    Si noti che viene visualizzata una finestra di messaggio che indica l'esito positivo.
  8. Nella finestra del database scegliere tabelle dall'elenco oggetti e quindi aprire la tabella tNewTable .

    Nota In Access 2007, tNewTable tabella facendo doppio clic su nel riquadro di spostamento.
  9. Modificare un record e provare a salvare le modifiche.
Si noti che quando si tenta di eseguire il commit di modifiche, si messaggio di errore su non dispone di sufficienti autorizzazioni. Ciò si verifica perché è assegnato il nuovo ruolo applicazione Seleziona autorizzazione sulla tabella tNewTable , ma non dell'autorizzazione di aggiornamento .

Per impostazione predefinita, Access vengono visualizzati soltanto oggetti nella finestra del database per il quale l'utente ha almeno SELECT oppure autorizzazioni di esecuzione. Access utilizza connessione # 1 per determinare quali oggetti di un utente ha autorizzazioni per. Dopo aver applicato l'applicazione ruolo finestra connessioni 2 e 3, il database include ancora gli stessi oggetti precedenza, anche se l'utente potrebbe non sono disponibili autorizzazioni a tutti gli oggetti o dispone di autorizzazioni a più oggetti che non vengono visualizzati. Questo può causare comportamento imprevisto quando si utilizza la finestra del database.

Ad esempio, quando aperta la tabella tNewTable, viene "visualizzato" che l'utente disporre di autorizzazioni modificare e inserire record. L'inserimento nuovo record icona sulla parte inferiore della tabella è attivato, e l'utente può inserire un record in modalità di modifica. Non è visualizzata qualsiasi indicazione visiva per indicare in caso contrario, fino a quando non si tenta di eseguire il commit della modifica o inserimento, il cui risultato è un messaggio di errore. Accesso ritiene che si dispone di autorizzazioni quando effettivamente non.

La soluzione più efficacia è fornire un'interfaccia personalizzata per l'utente e non affidarsi alla finestra del database. Un'interfaccia utente di tipo di pannello comandi consente di controllare esattamente quali oggetti che l'utente può accedere.

Altre limitazioni e considerazioni sulla protezione

le sottomaschere non funziona.

A differenza di altri oggetti di database, Access non utilizza sempre la stessa connessione per recuperare l'origine dati di una sottomaschera. Accesso spesso (ma non sempre) crea una nuova connessione a SQL Server per gestire il recordset sottomaschera o per recuperare i collegamento dati di campo che connette la sottomaschera alla maschera principale. Poiché il ruolo di applicazione non dispone di questa nuova connessione, potrebbe essere generato un errore di autorizzazioni se non si dispone di autorizzazioni esplicite all'oggetto di database. Sfortunatamente, questo significa che esiste alcun modo affidabile per utilizzare sottomaschere associate quando vengono applicati i ruoli applicazione. La soluzione di solo efficacia consiste nell'avere non associato le sottomaschere, completamente con la modifica di dati a livello di codice gestita. Si tratta di limitazione più grave quando si utilizzano i ruoli applicazione in Access.

report non funzionano

Quando si dispone di un oggetto come una tabella o un nome di visualizzazione è elencato come origine record per un report o un sottoreport, Access verifica se l'oggetto è presente nella finestra del database prima di recuperare i dati da SQL Server. Poiché la finestra del database utilizza una connessione che non è il ruolo di applicazione, viene generato un errore se non si dispone di autorizzazioni esplicite nell'origine dati sottostante.

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

ruolo del Database Public

Un ruolo applicazione acquisisce le autorizzazioni del ruolo public del database. Per impostazione predefinita, in NorthwindCS il ruolo di pubblico dispone di autorizzazioni complete per la maggior parte degli oggetti. Di conseguenza, un ruolo applicazione è in genere inefficace. Quando si crea la tabella tNewTable nella sezione "Creazione di un ruolo di applicazione", al ruolo public non è stato concesso autorizzazioni per la tabella e si è visto in un secondo momento gli effetti del contesto di protezione del ruolo dell'applicazione nella tabella. Altre tabelle tuttavia potrebbero non visualizzare alcuna differenza con il ruolo di applicazione poiché il ruolo public dispone di autorizzazioni a tali oggetti.

protezione VBA

Poiché la password per il ruolo di applicazione è incorporata nell'applicazione da cui viene chiamato, è possibile che un utente esperto sarà in grado di leggere il nome del ruolo di applicazione e la password dal codice sorgente e quindi utilizzare tali informazioni per accedere a SQL Server da un'altra applicazione. Pertanto è consigliabile compilare il ADP in un file ADE, in modo che il codice sorgente non sia visualizzabile. Come minimo, è possibile applicare una password per il progetto VBA.
ACC2002 reviewdocidACC2003 ACC2007
Riferimenti
Per ulteriori informazioni su una versione di Microsoft Access 2000 di questo articolo, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
318816ACC2000: Come utilizzare ruoli applicazione con progetti di Access e SQL Server 2000 Desktop Engine (MSDE 2000)
Per ulteriori informazioni su GRANT, vedere la Documentazione in linea di SQL Server . La Documentazione in linea di SQL Server è disponibile sul seguente sito Web:
http://www.microsoft.com/sql/techinfo/productdoc/2000/default.ASP

Proprietà

ID articolo: 308312 - Ultima revisione: 03/29/2007 17:22:00 - Revisione: 6.2

Microsoft Office Access 2007, Microsoft Office Access 2003, Microsoft Access 2002 Standard Edition

  • kbmt kbexpertiseinter kbinfo kbprogramming kbadp kbvba kbhowto KB308312 KbMtit
Feedback
text/javascript" src="https://c.microsoft.com/ms.js">