En Access tenemos unas herramientas que pueden llegar a resultarnos sumamente útiles cuando del análisis de la propia aplicación se trata. En este artículo os intento explicar de manera sencilla (espero que lo consideréis sencillo...) estas diferentes utilidades. Además, también os recomiendo una sorpresita... je, je...

Espero que os sea de utilidad. Un saludo, y... ¡suerte!

 

Bajarse pdf →  Pdf
Bajarse BD → BD

Si queréis bajaros el artículo en pdf pulsad aquí.

Archivadores

Algunas veces nos habremos encontrado con el hecho de que, al abrir una BD, parece que la BD no funciona bien: pulsamos los botones de los formularios, abrimos formularios, seleccionamos valores en un combo... y nada de nada. Parece como si la aplicación estuviese “muerta”.

Ello es así porque Access, por defecto, bloquea la ejecución de código. Es importante que actúe de esta manera porque podríamos recibir alguna BD con código malicioso, que se activara sólo por la acción de abrir la BD. Las consecuencias podrían ser nefastas.

EJECUCIÓN UNA SOLA VEZ


Para poder ejecutar el código, y en función de cómo tengamos configurado nuestro Access, es usual que, al iniciar la BD, nos aparezca algún mensaje indicándonos que el código se ha deshabilitado, dándonos la opción de habilitarlo.

ACCESS 2003

Si hablamos de Access 2003 nos encontraremos con diversos mensajes, como los siguientes:

UbiConf-03
Si pulsamos que NO queremos bloquearlas nos vuelve a advertir:

UbiConf-04


Y, lógicamente, para activar el código deberemos pulsar el botón ABRIR.


ACCESS 2007/2010

Si hablamos de Access 2007/2010 la advertencia nos viene dada por un mensaje “pegado” a la cinta de opciones.

UbiConf-01

Si clickamos sobre el botón “opciones” veremos que se nos abre una ventana con un “enorme” texto explicativo y dos opciones. Si marcamos la opción “Habilitar este contenido” conseguiremos que la BD se reinicie, aceptando esta vez la ejecución de código.

EJECUCIÓN SIEMPRE QUE ABRAMOS LA BD

ACCESS 2003

En Access 2003 el nivel de seguridad lo fija el nivel de ejecución de las macros. Para evitar que nos pida cada vez conformidad para ejecutar el código de la aplicación debemos seguir los siguientes pasos:

~ Nos vamos a menú Herramientas -> Macro -> Seguridad...

~ Seleccionamos el nivel de seguridad “Bajo”

Debemos ser conscientes de que, a partir de ese momento, permitiremos la ejecución de código en cualquier BD que abramos. Osea, que si no sabemos de dónde viene la BD... ¡cuidado!

ACCESS 2007/2010

En Access 2007 (y 2010) el sistema es diferente: debemos indicarle que queremos que la carpeta donde se encuentra la BD es una ubicación de confianza. ¿Y cómo hacemos eso?

El proceso es el siguiente:

~ Hacemos click sobre el botón de Office (menú Archivo para Access 2010)

~ Hacemos click sobre el botón “Opciones de Access” (“Opciones” para Access 2010),

~ En la ventana que se nos abre, a la izquierda, veremos una opción denominada “Centro de confianza”. Hacemos click sobre dicha opción.

~ Pulsamos sobre el botón “Configuración del centro de confianza...”

~ En la nueva ventana que nos sale, a la izquierda, tenemos la opción “Ubicaciones de confianza”. Hacemos click sobre dicha opción.

~ Y, ahora sí, vemos que tenemos diferentes botones para “Agregar nueva ubicación...”, “Quitar” y “Modificar”. Si la idea es agregar una nueva ubicación hacemos click sobre el botón correspondiente y se nos abrirá una ventana para navegar por nuestro PC. Seleccionamos la carpeta deseada y la añadimos.

UbiConf-02

Tened en cuenta que podemos marcar también la opción que indica que las subcarpetas de la carpeta seleccionada también son sitios de confianza.

También tened en cuenta que podemos permitir directamente ubicaciones de confianza que estén en red, marcando el check correspondiente (ver ilustración arriba).

Ni que decir tiene que para quitar o modificar una ubicación de confianza deberíamos realizar exactamente el mismo proceso, finalizando con la pulsación del botón correspondiente.

Y eso es todo. Un saludo y...

¡suerte!

Si queréis bajaros el artículo en pdf lo podéis hacer aquí.

Shift

Índice de contenido


DESHABILITANDO, DESHABILITANDO...
IMPORTANTE
¿EXISTIRÍA SOLUCIÓN SI…?
ACCESS 2007 (Y POSTERIOR). ¿QUÉ PASA SI LO COMBINO CON LA OCULTACIÓN DEL RIBBON?
PARA FINALIZAR...

 

DESHABILITANDO, DESHABILITANDO...
Hemos visto en el artículo sobre seguridad diferentes bloqueos para adoptar medidas de seguridad y proteger con eficacia nuestra aplicación, pero también hemos visto que el “truco” para que el administrador pueda abrir sin restricciones una BD consiste en mantener pulsada la tecla mayúsculas (shift) mientras se abre la BD.

En este artículo trataré de explicar de manera sencilla cómo podemos eliminar la acción de la tecla shift, y bloquear totalmente la BD.

Antes de comenzar debéis tener en cuenta una cosa extremadamente importante: realizado el proceso, no se podrá volver a abrir la BD para realizar modificaciones. En definitiva, que vamos a perder el control sobre la BD como administrador (bueno... esto es matizable, pero en principio, si somos un poco novatos, mejor nos quedamos con esta idea, que nos obligará a ir con mucho cuidado si queremos hacer pruebas).

Mi recomendación: no deshabilitar la función de la tecla shift. Y, si no tenemos más remedio, realizar el proceso cuando nos hayamos asegurado bien de que la aplicación funciona correctamente (con un buen periodo de testeo).

Finalmente, si seguimos con la idea de “emparedar” la aplicación, antes de realizar un determinado paso en el proceso que veremos a continuación (y sobre el que llamaré la atención en su momento) deberíamos guardar una copia de la BD para tener un “original” al que recurrir si hay problemas.

Ni que decir tiene que todo lo que se va explicar debe combinarse con el establecimiento de las opciones de no mostrar ventana base de datos o panel de exploración, según la versión de Access que utilicemos, y la restricción de los diferentes menús “generales” para los usuarios. Os recuerdo que esto está explicado en el artículo mencionado al principio.

Dicho lo anterior vamos a utilizar una función “famosa” para estos menesteres que se denomina AlterarPropiedades

Manos a la obra:

1.- Abrimos nuestra base de datos y pulsamos ALT+F11. Se nos abrirá el VBE (Editor de Visual Basic).
2.- Nos vamos al menú Insertar->Módulo
3.- En ese módulo escribimos la función antes mencionada:

---
Public Function AlterarPropiedades(strPropName As String, _
        varPropType As Variant, varPropValue As Variant) As Integer
    Dim dbs As Database, prp As Property
    Const conPropNotFoundError = 3270
    Set dbs = CurrentDb
    On Error GoTo Change_Err
    dbs.Properties(strPropName) = varPropValue
    AlterarPropiedades = True
Change_Bye:
    Exit Function
Change_Err:
    If Err = conPropNotFoundError Then ' Propiedad no ha sido localizada.
        Set prp = dbs.CreateProperty(strPropName, varPropType, varPropValue)
        dbs.Properties.Append prp
        Resume Next
    Else
            ' Error desconocido.
        AlterarPropiedades = False
        Resume Change_Bye
    End If
End Function
---

4.- Ahora es necesario obligar a que, al abrir la BD, se abra un formulario. Aunque esto está explicado en el artículo sobre seguridad lo resumo rápidamente aquí:
Botón de inicio (2007) o menú Archivo (2010)-> Opciones de Access -> Base de datos actual-> Mostrar formulario: 

Para Access 2003 el “camino” es

5.- Ponemos el formulario que va a ser nuestro inicio en vista diseño y sacamos sus propiedades. Nos vamos a Pestaña Eventos->Al abrir y generamos el siguiente código (nos situamos en la parte blanca que hay a la derecha del evento->Click sobre el botón que nos aparece con puntos suspensivos->Generar código):

---
Private Sub Form_Open(Cancel As Integer)
    AlterarPropiedades “AllowBypassKey”, dbBoolean, False
End Sub
---

6. Importante: es en este momento cuando debemos realizar la acción de salvaguardia de nuestra aplicación. Para ello al código anterior le situamos una comilla simple delante de cada línea del código anterior con la finalidad de convertir el procedimiento en un comentario. Con ello evitamos que, al abrir la BD, se ejecute el código y se bloquee definitivamente la BD.

Para mayor claridad el código debería quedar así:

---
'Private Sub Form_Open(Cancel As Integer)
'AlterarPropiedades "AllowBypassKey", dbBoolean, False
'End Sub
---

Cerramos la BD y creamos una copia, a la que identificamos como “Original”.

Volvemos a abrir la BD “no original”.

7.- Volvemos a editar las propiedades de nuestro formulario de inicio hasta acceder al código del evento “Al abrir”. Una vez en el código eliminamos las comillas simples de cada línea, de manera que ahora sí se pueda ejecutar el código.

8.- Para que el código pueda “activarse” es necesario abrir la BD de manera “normal” una sola vez. Para ello cerramos la BD y la volvemos a abrir (sin presionar shif).

9.- Una vez abierta la volvemos a cerrar. Ahora ya habremos “activado” el bloqueo de la tecla shift y, a partir de este momento, nuestra BD estará “emparedada” sin posibilidad de acceso a las “profundidades de la aplicación”


IMPORTANTE
Lo anterior bloquea la BD, pero no bloquea el código VB. Eso significa que si abrimos la BD y pulsamos ALT+F11 se nos abre el VBE con el código visible a la vista.

Para evitar que se pueda acceder al código, de nuevo, os remito al artículo sobre seguridad que comentábamos al principio de este artículo.

¿EXISTIRÍA SOLUCIÓN SI…?
Volver atrás lo hecho, una vez hecho, sí es posible si nos guardamos un “as en la manga”. Es decir, que si hemos creado un formulario al que sólo nosotros, como administrador, tenemos acceso, podemos programar un botón de comando para re-habilitar la funcionalidad de la tecla shift.

El proceso es muy sencillo, ya que a dicho botón de comando simplemente le deberíamos asignar este código:


Private Sub cmdHabilitar_Click()
    AlterarPropiedades "AllowBypassKey", dbBoolean, True
    MsgBox "La aplicación se cerrará para aplicar los cambios", vbInformation, "REINICIO"
    DoCmd.Quit
End Sub

Lógicamente, deberíamos abrir inmediatamente la BD con shift pulsado porque si no volvería a actuar el código del formulario de inicio.

Para que quede más claro os podéis bajar esta mini-aplicación de ejemplo aquí.

ACCESS 2007 (Y POSTERIOR). ¿QUÉ PASA SI LO COMBINO CON LA OCULTACIÓN DEL RIBBON?
Antes de empezar con esto supongo que alguien se preguntará: “¿Y cómo se oculta el ribbon?”. Pues para ocultarlo podríamos, por ejemplo, en el formulario que cargamos al inicio añadir el siguiente código en el evento de formulario “Al cargar”:


Private Sub Form_Load()
    DoCmd.ShowToolbar "Ribbon", acToolbarNo
End Sub

Lógicamente, lo único que tendremos que combinar son los dos códigos anteriores para poder conseguir ese “doble efecto”, de manera que podríamos escribir, en el evento “Al cargar” del formulario de inicio:


Private Sub Form_Load()
    DoCmd.ShowToolbar "Ribbon", acToolbarNo
    AlterarPropiedades “AllowBypassKey”, dbBoolean, False
End Sub

Finalmente, si quisiéramos volver a mostrar el ribbon la línea de código que nos haría lo anterior sería:


DoCmd.ShowToolbar "Ribbon", acToolbarYes

Para que lo podáis comprobar in situ podéis bajaros esta otra aplicación de ejemplo aquí.

PARA FINALIZAR...
Creo que eso es todo lo que os tenía que explicar sobre este tema. Espero que con lo que hemos aprendido podáis “emparedar” con toda tranquilidad vuestras BD's.

Un saludo, y...


¡suerte!

Si queréis bajaros este artículo en pdf pulsad aquí

seguridadOpacaTransp

Índice de contenido

¿SEGURIDAD OPACA? ¿SEGURIDAD TRANSPARENTE?
SABER QUÉ USUARIO ESTÁ USANDO EL PC
UN PEQUEÑO EJEMPLO PRÁCTICO
UTILIZANDO EL WINDOWS SCRIPT HOST PARA SACAR INFORMACIÓN DEL PC

¿SEGURIDAD OPACA? ¿SEGURIDAD TRANSPARENTE?
Si bien lo que hemos explicado sobre seguridad, tanto en el artículo dedicado a ello como en los ejemplos que hemos podido ver en la sección “ejemplos de seguridad”, es la sistemática más “usual”, vamos a desarrollar este breve artículo para hablar de dos conceptos interesantes: seguridad opaca y seguridad transparente (podréis encontraros con páginas que utilizan otra terminología para lo que vamos a exponer, pero el trasfondo del asunto es el mismo).

Cuando hablamos de un ordenador con Access lo que generalmente nos viene a la cabeza es un PC al alcance de todo el mundo, donde cualquier persona puede sentarse delante de él y hacer doble click para abrir nuestra BD. En este caso estamos hablando de seguridad opaca, porque no tenemos posibilidad de saber quién se va a sentar ahí e intentar acceder a nuestra aplicación.

Y es precisamente en este caso donde podemos poner en práctica todo lo que hemos aprendido en los artículos que comentábamos al principio: encriptar la BD, poner un formulario inicial de usuario y password, etc.

Pero hay otras circunstancias donde sí podemos saber qué usuario está “sentado” delante de ese ordenador. ¿Por qué? Porque el usuario no tiene más remedio, para acceder a Windows, que utilizar su nombre de usuario y password. E incluso, más allá, hay sistemas de acceso al sistema operativo que requieren una tarjeta de usuario, lo que limita aún más el hecho de que “cualquier persona” pueda utilizar ese ordenador.

Es en este segundo caso cuando hablamos de seguridad transparente.

La existencia de esta “seguridad transparente”, que ya nos crea un “paso de seguridad” previo y externo a nuestra BD, nos “facilita” la gestión de la seguridad de nuestra BD.

Y, como comentábamos en diferentes artículos de esta sección de Teoría/Práctica, tener en cuenta esta circunstancia nos puede ayudar muchísimo en el planteamiento del proyecto de lo que será nuestra BD.

SABER QUÉ USUARIO ESTÁ USANDO EL PC
Ahora la pregunta es, ¿y cómo podemos saber qué usuario está utilizando el PC? Para ello tenemos una función denominada “Environ”. Vamos a ver un pequeño ejemplo de cómo utilizar dicha función.

En una base de datos vacía, creamos un formulario en blanco. Lo situamos en vista diseño y creamos en él un botón de comando. Sacamos las propiedades de ese botón y nos vamos a la pestaña Eventos->Al hacer click. En dicho evento generamos código y escribimos, en el VBE, lo siguiente:

---
Private Sub Comando0_Click()
    Dim vUser As Variant
    
    vUser = Environ("UserName")
    
    MsgBox vUser
End Sub
---

Ahora, al hacer click sobre ese botón, nos aparecerá un MsgBox donde se nos informará del nombre de usuario que ha iniciado sesión en Windows.

Y supongo que alguien, al leer lo anterior, se preguntará, ¿y qué hago yo con esto? Vamos a desarrollar una pequeña aplicación práctica sobre lo explicado.

UN PEQUEÑO EJEMPLO PRÁCTICO

1.- Vamos a suponer que tenemos una aplicación en nuestra empresa, organización, casa o donde queramos, y que sólo queremos que la utilicen determinados usuarios, que, por supuesto, sabemos que entran en Windows a través de usuario y contraseña. Nosotros ya habremos hecho nuestra lista con los nombres de los usuarios a los que queremos permitir el acceso a nuestra BD (por ejemplo, ejecutando en cada sesión de usuario la mini-aplicación que hemos comentado antes).

2.- En nuestra aplicación creamos una tabla, a la que llamaremos TUsers, con un único campo, de tipo texto, al que llamaremos [nomUser] (no es necesario que sea clave principal). En esta tabla escribiremos los nombres de usuario a los que queramos permitir el acceso.

3.- Imaginemos que el formulario que se muestra al usuario, al abrir la base de datos, es FMenu.

Para aquellos que no sepan cómo hacer eso lo explico aquí muy rápidamente:

3.1.- Creamos un formulario en blanco y lo guardamos como FMenu
3.2.1.- Para usuarios de  Access 2007: hacemos click sobre el botón de Office ? Opciones de Access ? Base de datos actual ? Mostrar Formulario, y seleccionamos FMenu
3.2.2.- Para usuarios de Access 2010: menú Archivo ? Opciones ? Base de datos actual ? Mostrar Formulario, y seleccionamos FMenu
3.2.3.- Para usuarios de Access 2003: menú Herramientas ? Inicio… ? Mostrar Formulario, y seleccionamos FMenu

4.- Situamos FMenu en vista diseño, sacamos sus propiedades, y en el evento “Al abrir” generamos el siguiente código:

---
Private Sub Form_Open(Cancel As Integer)
    Dim vUser, vComp As Variant
    vUser = Environ("UserName")
    
    vComp = DLookup("[nomUser]", "TUsers", "[nomUser]='" & vUser & "'")
    
    If IsNull(vComp) Then
        MsgBox "No está autorizado para abrir esta BD", vbCritical, "RESTRINGIDO"
        DoCmd.Quit
    End If
End Sub
---

Y ya está. Si el usuario está dado de alta en nuestra tabla podrá acceder a la BD; en caso contrario se le avisará de que ello no es posible.

UTILIZANDO EL WINDOWS SCRIPT HOST PARA SACAR INFORMACIÓN DEL PC
Podemos utilizar, siguiendo en la línea de lo que estamos explicando, lo que se denomina “script host” para poder obtener datos del PC.

Para ello debemos escribir un código, por ejemplo en un botón de comando, el siguiente código:


Private Sub cmdWSH_Click()
    Dim wshNetwork As Object 'Nuevo wshNetwork
    Set wshNetwork = CreateObject("WScript.Network")
    MsgBox "Nombre del equipo: " & wshNetwork.ComputerName
    MsgBox "Nombre del dominio: " & wshNetwork.UserDomain
    MsgBox "Nombre de usuario: " & wshNetwork.UserName
    Set wshNetwork = Nothing
End Sub

Este código nos proporcionará información del nombre del equipo, del dominio y del usuario.

Si quisiéramos acoplar el código del epígrafe anterior simplemente deberíamos hacer que la variable vUser se igualara a wshNetwork.UserName, combinando ambos códigos.

Si queréis bajaros la mini aplicación de ejemplo podéis hacerlo aquí. Recordad que no podréis entrar en la BD (a no ser que vuestro nombre de usuario coincida con los que hay dados de alta en la tabla TUsers). Para abrirla como administrador debéis mantener la tecla mayúsculas (shift) pulsada al tiempo que se abre la BD.

Espero que lo anterior os sea de utilidad.

Un saludo, y...

¡suerte!

Si queréis bajaros este artículo en pdf pulsad aquí

seguridad

Índice de contenido


¿QUÉ NOS CUENTA ESTE ARTÍCULO?
SEGURIDAD POR USUARIOS DE ACCESS 2003: CREACIÓN DE GRUPOS Y PERMISOS
INCORPORACIÓN DE UNA CONTRASEÑA A NUESTRA BASE DE DATOS
OCULTANDO ELEMENTOS DE LA BD AL ABRIRLA
OCULTANDO TOTALMENTE EL RIBBON / BARRA DE MENÚS
PROTEGIENDO A TRAVÉS DE UN FORMULARIO DE ACCESO CON CONTRASEÑA
PROTEGIENDO NUESTRO CÓDIGO VBA
CONVIRTIENDO NUESTRA BD A UN ARCHIVO MDE / ACCDE
CONVERTIR NUESTRO ARCHIVO ACCDE EN EXTENSIÓN DE RUNTIME (ACCDR)
PARA FINALIZAR...

 

¿QUÉ NOS CUENTA ESTE ARTÍCULO?
La idea no es entrar en excesivo detalle en temas de seguridad, sino dar un par de pinceladas (algunas más profundas que otras) para que podáis tener una visión un poco más “general” de algunos aspectos que conciernen a la seguridad de nuestra base de datos.

Se explicarán algunas características de seguridad, algunos trucos y todo lo que se me ocurra, todo ello en vistas a proteger nuestra aplicación de “usuarios indiscretos”.

Creo importante señalar , y como algo que deberíamos tener en mente mientras leemos este texto, es que lo ideal, según las características de nuestra BD, sería combinar diversos tipos de elementos que aquí se explican para lograr el nivel de protección que deseemos.

Y dicho esto vamos a por la “chicha”.

 

SEGURIDAD POR USUARIOS DE ACCESS 2003: CREACIÓN DE GRUPOS Y PERMISOS
En este apartado no entraré en ningún tipo de explicación... básicamente porque creo que sería incapaz de superar lo que ya se ha escrito.

Os dejo un pdf, archivo que podéis bajar aquí, de una página donde se explica con detalle cómo conseguir este nivel de seguridad a través de varios métodos.
La página ya no está operativa, pero por si os interesa era: http://www.hispavila.com/3ds/office/seguridadaccess.html

 

INCORPORACIÓN DE UNA CONTRASEÑA A NUESTRA BASE DE DATOS
Este sistema es el que yo denomino “seguridad de viaje”. Resulta bastante incómodo cifrar nuestra aplicación con una contraseña y que cada vez que vayamos a abrir la BD nos pida una contraseña, máxime si después tenemos algún formulario que nos solicita de nuevo otra contraseña para acceder a los contenidos de la BD.

Sin embargo, es un sistema 3B (bueno, bonito, barato) para transportar nuestra BD de un sitio a otro y no preocuparnos de que alguien pueda “husmear” por nuestra base de datos.

Evidentemente, lo anterior es sólo una idea y el cifrado de la base de datos puede utilizarse como mecanismo habitual de seguridad sin problema, si se adapta a lo que necesitamos.

¿Y cómo ciframos la BD? Pues de la siguiente manera:

Para poder aplicar la contraseña debemos abrir la BD en modo exclusivo. Para ello abrimos un Access (probablemente la ruta que tengamos sea algo parecido a Inicio -> Programas -> Microsoft Office -> Access). Una vez abierto pulsamos sobre el botón de Office (Menú Archivo para 2010) y seleccionamos la opción “Abrir”. Navegamos hasta nuestra BD y la seleccionamos. Veremos que el botón “Abrir” tiene una flecha a la derecha. Si pulsamos sobre ella nos sale un desplegable con las diversas opciones de apertura. Ahí clickamos sobre “Abrir en modo exclusivo”.

A partir de ahí las cosas son ligeramente diferentes según la versión de Access que estemos utilizando.


 ACCESS 2003

Nos vamos a Menú Herramientas -> Seguridad -> Establecer contraseña para base de datos. Nos aparecerá una ventana donde se nos solicitará la introducción y reintroducción de una contraseña... y listos.

Para descifrar la BD debemos seguir el mismo camino.


 ACCESS 2007/2010

Una vez abierta nos vamos al menú “Herramientas de la base de datos”, y al grupo de opciones del mismo nombre. Ahí veremos una opción, que se denomina “ Cifrar con contraseña”. Si hacemos click sobre ese botón veremos que se nos solicita una contraseña (y su confirmación).

Establecida esta contraseña ya tenemos nuestra BD cifrada y asegurada.

Para descifrar la BD el proceso es exactamente el mismo, recordando que debemos abrir de nuevo la BD en modo exclusivo.

 

OCULTANDO ELEMENTOS DE LA BD AL ABRIRLA
Cuando abrimos una BD nos aparece la ventana de base de datos (2003) o el panel de exploración (2007/2010). Nos aparece también o bien los menús y las barras de menú (2003) o bien la cinta de opciones con todas las opciones disponibles y activas (2007/2010).

¿Cómo conseguir que esto no suceda?

Pues bien, vamos a verlo en función de la versión que tengamos:


 ACCESS 2003

Nos vamos a menú Herramientas -> Inicio... Nos aparecerá una nueva ventana. Si ahí desmarcamos los checks “Permitir el uso de menús no restringidos”, “Permitir el uso de menús contextuales predeterminados” lo que hacemos es, precisamente, eliminar la posibilidad de que el usuario pueda utilizar los menús de Access y los menús contextuales que nos aparecen al pulsar el botón derecho del ratón.

Si, además, ahí desmarcamos el check correspondiente a “Presentar la ventana Base de datos”, ya no nos aparecerá la ventana Base de datos.

A partir de aquí podéis saltar a línea “Unos comentarios”, de este mismo artículo.


 ACCESS 2007/2010

Si pulsamos sobre el botón de Office (menú Archivo en 2010) veremos un botón llamado “Opciones de Access”. Si clickamos sobre el mismo veremos que nos aparece una pantalla con las diferentes opciones de Access.

A la izquierda de dicha pantalla tenemos una opción denominada “Base de datos actual”. La seleccionamos y podremos comprobar que, a la derecha, nos aparecen unos epígrafes con el tipo de opción a modificar. Por ejemplo, el primer epígrafe que podemos ver se denomina “Opciones de aplicación” (por cierto, que dentro de esas opciones podríamos poner el título de la BD y asociar un icono a la misma).

El segundo epígrafe, “Exploración”, contiene una casilla de verificación. Si la desmarcamos, evidentemente, lo que conseguiremos es que al abrir la BD no aparezca nuestro panel de exploración.

El tercer epígrafe, “Opciones de la barra de herramientas y de la cinta de opciones”, contiene varias opciones. A nuestros efectos nos centraremos de nuevo en las dos casillas de verificación.

Si desmarcamos el primer check lo que conseguimos es que la cinta de opciones aparezca sólo con las mínimas opciones disponibles, básicamente las correspondientes a Menú Inicio.

Si desmarcamos el segundo check lo que conseguimos es que no aparezca el menú contextual cuando hacemos click con el botón derecho del ratón sobre los diferentes objetos de la BD.


 Unos comentarios:

En primer lugar, os recomiendo que si vais a utilizar esta configuración, fijéis un formulario de inicio, porque si no la BD se os abrirá “en blanco”. Para configurar dicho formulario de inicio, cuando estéis situados en las opciones de Access, veréis que en el primer epígrafe hay una opción denominada “Mostrar formulario”. Ahí podéis seleccionar el formulario que aparezca en primer lugar cuando se abra la BD.

En segundo lugar, tened en cuenta que con esta configuración, al hacer click sobre el botón de Office (Menú Archivo en 2010), las opciones que ahí podíais encontrar ya no estarán. Es decir, que este sistema nos “protege” también las mismas.

Si queremos entrar como administrador en la BD deberemos abrirla manteniendo en todo momento la tecla mayúsculas (shift) pulsada.

Finalmente, y tras lo comentado en el párrafo anterior, os recomiendo que echéis un vistazo a este artículo, donde se explica cómo bloquear también el acceso con la tecla shift (pero andad con mucho cuidado puesto que si os equivocáis podríais perder el control de la BD como administrador)

 

OCULTANDO TOTALMENTE EL RIBBON / BARRA DE MENÚS
Para conseguir la ocultación total de la barra de menús (2003) o del ribbon (2007/2010) debemos recurrir ya a programación.

El sistema es muy sencillo: utilizaremos el formulario de inicio que hemos indicado en el apartado anterior para asignarle el código VBA que nos oculte la cinta de opciones o la barra de menús.

El procedimiento sería el siguiente:

Situamos el formulario de inicio en vista diseño. Sacamos sus propiedades y nos vamos a la pestaña Eventos ? Al abrir, y le generamos el siguiente código (Access 2003):


Private Sub Form_Open(Cancel As Integer)
    DoCmd.ShowToolbar "Menu Bar", acToolbarNo
End Sub

O el siguiente código (para Access 2007/2010):


Private Sub Form_Open(Cancel As Integer)
    DoCmd.ShowToolbar "ribbon", acToolbarNo
End Sub

Claro que, en este caso, debemos tener muy en cuenta que todas las operaciones en la BD deben poderse realizar desde nuestros formularios, ya que no dispondremos de ningún botón ni menú contextual si hemos configurado Access según se indicaba en el apartado anterior.

 

PROTEGIENDO A TRAVÉS DE UN FORMULARIO DE ACCESO CON CONTRASEÑA
Una vez que entramos en la BD (a través de nuestro formulario de inicio) podemos proteger el acceso a través de una contraseña, incluso discriminando el tipo de usuario o el nivel de acceso de cada uno de los usuarios.

En este sentido tenéis la sección Ejemplos de Seguridad de la web donde podréis examinar diferentes sistemáticas relacionadas con la seguridad.

 

PROTEGIENDO NUESTRO CÓDIGO VBA
Para evitar miradas indiscretas a nuestros códigos también podemos proteger nuestro código VBA.

El procedimiento para conseguir eso es el siguiente:

Abrimos nuestra BD.
Pulsamos la combinación del teclas ALT+F11. Eso nos abrirá el editor de VB.
Nos vamos a Menú Herramientas -> Propiedades de XXX.

Se nos abrirá una nueva ventana con dos pestañas. Nos vamos a la pestaña “Protección”.

Marcamos el check “Bloquear proyecto para visualización”
Establecemos nuestra contraseña, y su confirmación.

Con esto nuestro código VB no se mostrará, salvo que introduzcamos la contraseña de desbloqueo.

Tened en cuenta también que si queremos importar los objetos de una BD a la que hayamos bloqueado el código VB a una BD nueva no nos va a ser posible si esos objetos tienen código VB asociado. Para poder realizar esta opción deberíamos:

Abrir la BD que tiene el código VB bloqueado y desbloquearlo
Realizar la importación
Volver a bloquear nuestro VB

 

CONVIRTIENDO NUESTRA BD A UN ARCHIVO MDE / ACCDE
Si convertimos nuestra BD en un archivo mde o accde obtenemos una seguridad parcial. Para resumir, y citando las palabras del propio Microsoft:

La interfaz de usuario estará desactivada para modificar o crear formularios, informes o módulos. El cuadro de diálogo Referencias de VBA no permitirá agregar, eliminar o cambiar referencias a bases de datos o bibliotecas de objetos. 
El código fuente no estará disponible. 
Los comandos de importación y exportación estarán deshabilitados para formularios, informes o módulos. Sin embargo las tablas, consultas, páginas de acceso a datos y macros se pueden importar o exportar a bases de datos no MDE.

Os recomiendo, si estáis interesados en profundizar sobre este tema, las propias explicaciones de Microsoft. Aunque hable de mde las explicaciones son extensibles a lo que sería un archivo accde: http://office.microsoft.com/es-es/access-help/archivos-mde-mdb-HP005239302.aspx

Para crear un archivo mde simplemente debemos seguir la ruta Menú Herramientas -> Utilidades de la base de datos -> Crear archivo MDE.

Si hablamos de accde nos vamos a Menú Herramientas de Base de Datos -> Grupo de opciones  Herramientas de Base de Datos -> Crear ACCDE

 

CONVERTIR NUESTRO ARCHIVO ACCDE EN EXTENSIÓN DE RUNTIME (ACCDR)
Mención especial podemos hacer del pequeño “truco” de cambiar nuestra extensión normal de Access a una extensión que el propio Access reconoce como extensión de archivo Runtime.

Deberemos tener en cuenta que para poder utilizar esta opción nuestro sistema operativo deberá estar configurado para “no ocultar las extensiones de archivo”. Para hacer esto debemos acceder, abriendo cualquier carpeta, a las opciones de carpeta y en la pestaña “VER” desmarcar el check de la opción "Ocultar las extensiones de archivo para tipos de archivo conocidos". Una búsqueda por Internet os explicará con detalle este proceso, si no sabéis hacerlo.

 

PARA FINALIZAR...
Hemos visto diferentes sistemas y formas para proteger nuestra BD. Hay algunos otros sistemas adicionales por “esos mundos de Internet”, pero, desde mi punto de vista, son eso: sistemas adicionales para complementar lo que se ha visto aquí.

Una buena combinación de métodos probablemente ofrecerá un nivel de protección adecuado según nuestras necesidades.

Espero que el artículo os sea de utilidad.

Un saludo, y...

¡suerte!