Avanzado: Requiere conocimientos avanzados de codificación, interoperabilidad y multiusuario.

En este artículo sólo se aplica a un proyecto de Microsoft Access (.adp).


Para una versión de Microsoft Access 2000 de este artículo, consulte
318816.

Resumen

Este artículo explica las capacidades, las limitaciones y las soluciones para el uso de las funciones de aplicación de Microsoft SQL Server en un proyecto de Microsoft Access (ADP).

Más información

En SQL Server, puede crear funciones de base de datos para facilitar la administración de permisos en una base de datos. En lugar de conceder permisos individuales para cada usuario por separado, puede agrupar los usuarios que tengan las mismas necesidades de permiso les hace miembros de la misma función de base de datos normal y, a continuación, asignar permisos a la función de base de datos propia. A menos que un permiso específico se deniegue explícitamente en otro lugar, los usuarios miembro obtendrá los permisos concedidos a esa función de base de datos.

Mientras que las funciones de base de datos normal son muy útiles en situaciones donde desea que los usuarios puedan realizar sus propias consultas ad hoc o actualizaciones a una base de datos, no siempre son adecuados. A veces, puede que desee los usuarios sólo tengan determinados permisos cuando utilizan una aplicación específica y no desea que puedan ver o modificar datos fuera de la aplicación.

Un método que se utiliza a menudo para solucionar esto es darle sólo los permisos necesarios para una cuenta de usuario de SQL Server. Los usuarios reales que tienen permisos para conectarse a una base de datos pero no para ver o modificar los datos. Después de que un usuario se conecta a la base de datos mediante la cuenta de usuario individual, el ADP podría a continuación, mediante programación vuelva a conectar utilizando las credenciales de la cuenta de usuario que tienen permisos. Aunque puede ser efectiva, no permite distinguir entre usuarios en la base de datos o para determinar qué usuario realiza una acción determinada.

Las funciones de aplicación están diseñadas para evitar esta limitación. Las funciones de aplicación, a diferencia de las funciones de base de datos normal, no tienen miembros propios. En su lugar, los usuarios iniciar sesión en un SQL Server y conectan a una base de datos utilizando sus propias credenciales. En ese momento, el contexto de seguridad de una función de aplicación puede aplicarse mediante programación a una conexión existente mediante el procedimiento almacenado sp_setapprole . En SQL Server, todavía se diferencian los usuarios individuales, pero los permisos que están disponibles en una conexión determinada están limitados a los permisos de la función de aplicación. Los permisos del usuario individual, ya sea menor o mayor, ya no se consideran.

Crear una función de aplicación

Proyectos de Microsoft Access no tienen ninguna herramienta de diseño visual para crear objetos de seguridad de SQL Server, como las funciones de aplicación. Microsoft recomienda que utilice las herramientas de cliente que se incluyen con la versión normal de SQL Server o Microsoft Office XP Developer para crear la función de aplicación y asignar permisos. Sin embargo, todavía puede crear la función de aplicación y otorgarle los permisos necesarios mediante programación utilizando Transact-SQL (T-SQL) desde un ADP. Aunque una discusión completa de seguridad de SQL Server está fuera del alcance de este artículo, adicional puede encontrar información en los Libros en pantalla de SQL Server los pasos siguientes muestran cómo crear una función de aplicación mediante programación y conceder a la nueva función Seleccione permisos en una tabla:

  1. Inicie Access.

  2. Abra el proyecto de ejemplo de Access Neptuno.

  3. En la ventana Base de datos, haga clic en módulos , bajo objetosy, a continuación, haga clic en nuevo para abrir un nuevo módulo en el entorno de Visual Basic.

    Nota: En Access 2007, haga clic en módulo en el grupo otros de la ficha crear .

  4. Escriba o pegue el código siguiente en el nuevo módulo:

    Public Function AddNewAppRole(RoleName As String, PW As String) As Boolean
    On 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. Guarde el módulo y, a continuación, salir del entorno de Visual Basic.

  6. Crear una copia de la tabla Customers y, a continuación, guárdelo como tNewTable. Para ello, siga estos pasos:

    1. En la ventana Base de datos, haga clic en la tabla Customers y, a continuación, haga clic en Guardar como en el menú contextual.

      Nota: En Access 2007, haga clic en la tabla Customers en el panel de exploración, haga clic en el Botón de Microsoft Office, elija Guardar comoy, a continuación, haga clic en Guardar objeto como.

    2. En el cuadro de diálogo Guardar como , escriba tNewTable en el cuadro Guardar tabla 'Clientes' para y, a continuación, haga clic en Aceptar.

  7. En la ventana Base de datos, haga clic en formularios bajo objetos, haga clic en nuevoy, a continuación, haga clic en Aceptar para abrir un nuevo formulario en la vista Diseño.

    Nota: En Access 2007, haga clic en Diseño de formulario , en el grupo formularios de la ficha crear .

  8. Agregue un botón de comando al formulario de nuevo.

  9. Establezca la propiedad AlHacerClic (OnClick) del botón de comando nuevo en el procedimiento de evento siguiente:

    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. Cierre el entorno de Visual Basic para volver al formulario.

  11. Guarde el formulario y, a continuación, cambie el formulario a la vista Formulario.

  12. Haga clic en el botón de comando para ejecutar el código subyacente.

    Observe que recibe dos cuadros de mensaje para indicar el éxito. Recibe uno después de crea la función de aplicación y se conceden en el segundo se después los nuevos permisos de función para tNewTable.

Implementar la función de aplicación

El principal problema al utilizar las funciones de aplicación en proyectos de Access es que Access utiliza tres conexiones a SQL Server para manejar diversas tareas. Idealmente, para aplicar una función de aplicación a todo el proyecto, tendría que ejecutar sp_setapprole en el contexto de todas las conexiones de tres. Los objetos controlados por cada conexión son los siguientes:

  1. Se utiliza para determinar los objetos que aparecen en la ventana Base de datos y tareas administrativas de base de datos variada.

    Se utiliza para abrir tablas, vistas, procedimientos almacenados, funciones y los orígenes de registros para formularios e informes secundarios (pero no para el propio informe principal).

    Se utiliza para obtener los orígenes de registros para informes, cuadros de lista y cuadros combinados.

  2. Se utiliza para abrir tablas, vistas, procedimientos almacenados, funciones y los orígenes de registros para formularios e informes secundarios (pero no para el propio informe principal).

    Se utiliza para obtener los orígenes de registros para informes, cuadros de lista y cuadros combinados.

  3. Se utiliza para obtener los orígenes de registros para informes, cuadros de lista y cuadros combinados.


Aunque las conexiones #2 y #3 pueden tener acceso fácilmente, no hay ningún método disponible para ejecutar el procedimiento almacenado en el contexto de conexión #1. Afortunadamente, esta conexión es la menos importante de los tres y fácilmente solucionada mediante la creación de su propia interfaz de usuario (por ejemplo, un formulario de tipo de panel de control) para controlar objetos de base de datos en lugar de confiar en la ventana Base de datos integrada.

Los pasos siguientes utilizan el proyecto de ejemplo de Access Neptuno para demostrar cómo aplicar una función de aplicación con conexiones #2 y #3:

  1. En la ventana Base de datos, haga clic en formularios bajo objetos, haga clic en nuevoy, a continuación, haga clic en Aceptar para abrir un nuevo formulario en la vista Diseño.

    Nota: En Access 2007, haga clic en Diseño de formulario , en el grupo formularios de la ficha crear .

  2. Agregue un cuadro de lista en el formulario recién creado y, a continuación, establezca la propiedad Name del cuadro de lista a lst_AppRole.

  3. Agregue un botón de comando al formulario.

  4. Establezca la propiedad AlHacerClic (OnClick) del botón de comando nuevo en el procedimiento de evento siguiente:

    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. Cierre el entorno de Visual Basic para volver al formulario.

  6. Guarde el formulario y, a continuación, cambie el formulario a lavista Formulario.

  7. Haga clic en el botón de comando para ejecutar el código subyacente.

    Observe que aparece un cuadro de mensaje que indica éxito.

  8. En la ventana Base de datos, haga clic en tablas bajo objetosy, a continuación, abra la tabla tNewTable .

    Nota: En Access 2007, haga doble clic en tabla de tNewTable en el panel de exploración.

  9. Modificar un registro y guardar los cambios.

Observe que, como intentar confirmar los cambios, recibirá un mensaje de error por no tener permisos suficientes. Esto ocurre porque dio la nueva función de aplicación, Seleccione permiso en la tabla tNewTable , pero no
Permiso de actualización .

Por diseño, Access sólo muestra objetos en la ventana Base de datos para el que el usuario seleccione al menos o permisos de ejecución. Access utiliza conexión #1 para determinar qué objetos de un usuario tiene permisos para. Después de aplicar la función de aplicación a las conexiones #2 y #3, la ventana Base de datos todavía muestra los mismos objetos que antes, aunque el usuario ya no tiene permisos para todos los objetos, o que tenga permisos para varios objetos que no se muestran. Esto puede producir un comportamiento inesperado cuando utiliza la ventana Base de datos.

Por ejemplo, al abrir la tabla tNewTable, "parece" que el usuario tiene permisos para editar e insertar registros. El icono de insertar nuevo registro en la parte inferior de la tabla está habilitado y el usuario es capaz de poner un registro en modo de edición. No verá ninguna pista visual para indicar lo contrario hasta que intenta confirmar la edición o inserción, lo que provoca un mensaje de error. Access cree que dispone de permisos cuando en realidad no lo hace.

La solución más efectiva es proporcionar una interfaz personalizada para el usuario y no dependen de la ventana Base de datos. Mediante una interfaz de usuario de tipo de panel de control, puede controlar exactamente qué objetos que el usuario tiene acceso a.

Otras limitaciones y consideraciones de seguridad

Subformularios no funciona

A diferencia con otros objetos de base de datos, Access no siempre utiliza la misma conexión para recuperar el origen de datos de un subformulario. Acceso con frecuencia (pero no siempre) crea una nueva conexión a SQL Server sólo para controlar el conjunto de registros del subformulario, o para recuperar los datos del campo de vinculación que se conecta el subformulario al formulario principal. Debido a esta nueva conexión no tiene la función de aplicación, puede generarse un error de permisos si no tiene permisos explícitos para el objeto de base de datos. Desafortunadamente, esto significa que no hay ninguna forma confiable de utilizar subformularios enlazados cuando se aplican las funciones de aplicación. La solución efectiva sólo es completamente han independiente subformularios, con la manipulación de datos controlada mediante programación. Ésta es la limitación más grave cuando se utilizan funciones de la aplicación en Access.

Informes no funciona

Cuando se tiene un objeto como una tabla o un nombre de vista se muestra como origen de registros para un informe o subinforme, Access comprueba si el objeto aparece en la ventana Base de datos antes de recuperar todos los datos de SQL Server. Dado que la ventana Base de datos utiliza una conexión que no tiene la función de aplicación, se genera un error si no tiene permisos explícitos en el origen de datos subyacente.

Para evitar este problema, utilice siempre las instrucciones de Transact-SQL como origen de registros para formularios e informes. Por ejemplo, utilice "Seleccionar * de ViewName" en lugar de simplemente "ViewName" o "Exec StoredProcedureName" en lugar de simplemente "StoredProcedureName". De este modo, Access pasa las instrucciones de Transact-SQL directamente a SQL Server y recupera los datos según los permisos de la función de aplicación.

La función de base de datos pública

Una función de aplicación adquiere los permisos de la función de base de datos pública. De forma predeterminada en NorthwindCS, la función Public tiene permisos completos para la mayoría de los objetos. Por lo tanto, una función de aplicación es generalmente ineficaz. Cuando crea la tabla tNewTable en la sección "Crear una función de aplicación", la función pública no se ha concedido permiso a la tabla y más adelante vio los efectos del contexto de seguridad de la función de aplicación en esa tabla. Sin embargo, otras tablas pueden no mostrar ninguna diferencia en la función de aplicación debido a la función Public tiene permisos a esos objetos.

Seguridad VBA

Dado que la contraseña de la función de aplicación está incrustada en la aplicación desde la que se llama, un usuario experimentado sería capaz de leer el nombre de la función de aplicación y la contraseña desde el código fuente y, a continuación, utilizar esa información para obtener acceso a SQL Server desde otra aplicación. Por lo tanto, es una buena idea compilar el ADP en un archivo ADE para que no se puede ver el código fuente. Como mínimo, exige una contraseña en el proyecto de VBA.

Referencias

Para obtener información adicional acerca de una versión de Microsoft Access 2000 de este artículo, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

318816 ACC2000: cómo utilizar las funciones de aplicación con proyectos de Access y SQL Server 2000 Desktop Engine (MSDE 2000)
Para obtener más información acerca de la concesión, vea Libros en pantalla de SQL Server. Los Libros en pantalla de SQL Server está disponible en el sitio Web de Microsoft siguiente:

http://www.microsoft.com/sql/techinfo/productdoc/2000/default.asp

¿Necesita más ayuda?

Ampliar sus conocimientos
Explorar los cursos
Obtener nuevas características primero
Unirse a Microsoft Insider

¿Le ha sido útil esta información?

¿Cuál es tu grado de satisfacción con la calidad del lenguaje?
¿Qué ha afectado a tu experiencia?

¡Gracias por sus comentarios!

×