Base de datos con Multiusuarios segunda parte

Nota del editor: Esta es una serie de varias partes, si desea ver la parte uno click Aqui. 

(Juan continuará la serie porque Mark ya no se encuentra trabajando en la empresa).

En esta segunda parte continuamos explorando el concepto de  multiusuarios en las aplicaciones de base de datos en Microsoft Access.

Hay dos forma principales para lograr un diseño de base de datos multiusuarios. En la primera parte hemos descrito los problemas más comunes cuando se utiliza la separación física como patrón de diseño de una base de datos. Aquí veremos el diseño de la separación lógica y algunas sugerencias de técnicas para la implementación.

La Separación lógica: Es menos segura, pero provee un método más fácil de agregar datos.

Si el objetivo del diseño de nuestra aplicación y las reglas del negocio especifican que los diferentes usuarios necesitarán acceso a infraestructuras de datos comunes (por ejemplo, a una parte de la lista del inventario). Entonces nuestra aplicación podrá compartir al menos una parte de la estructura física de la base de datos.

En general, si las reglas del negocio o requerimientos para agregar datos son de muchos privilegios o los requisitos de almacenamiento de datos son muy pocos, entonces en la práctica es más simple y más fácil de compartir una estructura física de la base de datos. Esto puede incluir un diseño de tablas «más amplio»  del que se necesitaría para  un  usuario único, los campos adicionales necesitados por otro usuario pueden compartir la misma estructura básica de tablas sin incurrir en las desventajas de tablas adicionales  (y sus índices, declaraciones y relacionales de integridad etc.).

Vamos a considerar dos posibles enfoques. El primer enfoque funciona bien cuando estamos usando una tabla de usuario para almacenar el inicio de sesión en la aplicación y el uso de un inicio de sesión SQL compartido junto con TempVars. El segundo enfoque asume que cada usuario tiene su propia conexión SQL lo que nos permite utilizar los views de SQL y forzar un  filtro de datos.

Técnica 1: Utilizando un inicio de sesión único de SQL Server para la aplicación completa

En nuestra empresa nos especializamos en aplicaciones multiusuarios, (¡llámenos y nosotros nos encargamos de hacerlo por usted!), Y casi siempre usamos una tabla de usuarios para identificar el usuario y un solo inicio de sesión para todos los usuarios. El inicio de sesión se utiliza en el código VBA para iniciar la conexión a SQL Server y vincular las tablas. Los usuarios se gestionan a través de una tabla tblUsers y cuando se abre una sesión que no es hecha por SQL Server, sino más bien por el código que valida sus credenciales a través de las tablas. SQL Server usa la misma sesión con el mismo nombre de usuario para todos los usuarios.

TempVars hace que todo suceda

Para activar la separación de datos en su aplicación, va a tener que hacer lo mismo en todos los niveles: formularios, informes, consultas y códigos. Y la forma más fácil y más confiable de hacerlo es con  TempVars. (Click here to learn more about them).

Paso 1: Utilice un formulario de Access para identificar al usuario y así limitar el acceso a los datos

Con bastante frecuencia diseñamos aplicaciones donde los usuarios pueden acceder a una identidad (oficinas y franquicias). Por ejemplo, ya sea escogiendo de una lista o simplemente cargar su segmento si sólo está autorizado para una sola. Al hacerlo nos fijamos en el control TempVar que proveerá los datos que usted verá en la aplicación.

Por ejemplo, en una aplicación teníamos un cliente con un pequeño requerimiento en el que se necesitaba guardar los datos en dos ubicaciones de la empresa por separados. Los empleados fueron asignados a una oficina en particular de forma predeterminada, pero no podían hacer el trabajo de otras oficinas o atender a los clientes de otras oficinas.

La clave principal para agregar los datos en este caso fue OfficeID (una clave principal de una tabla tblOffices). Así que al iniciar la sesión, se consigue el OfficeID del usuario en la base de datos y la guarda en una variable nueva llamada TempVars con estas sintaxis:

TempVars.Add » OfficeID “, lngUserOfficeID

A partir de entonces, al valor fácilmente se le puede hacer referencia mediante el uso de:

TempVars (» OfficeID «) o TempVars ! OfficeID

TempVars.Add “OfficeID”, lngUserOfficeID

Thereafter, the value can easily be referenced by using:

TempVars(“OfficeID”) or TempVars!OfficeID

Paso 2: Diseñe sus consultas, formularios e reportes para cargarlos con el TempVar

Diseñe todos sus objetos primarios para utilizarlos en una cláusula WHERE con su limitante TempVar. Si se trata de una consulta se utilizaría el TempVar como criterio, por ejemplo:

Select * From tblCustomers Where OfficeID = TempVars!OfficeID

Observe cómo ACE entiende el uso de TempVars en la cláusula Where.

Diseñe sus principales formularios y reportes para que utilice una consulta y utilice TempVar para filtrar como la cláusula WHERE en la propiedad de su fuente de datos.            . Los  sub-formularios/reportes no los necesitan si va a conectar al sub-principal a través de un enlace en las claves secundarias/primarias de cada tabla subyacente. En otras palabras, no enloquezca añadiendo la cláusula WHERE en cada fuente de datos y en cada subformulario. Para que utilizar TempVar cuando todo lo que necesita es usar un  enlace.

Paso 3: Utilice ADODB  y TempVars para conseguir los datos correctos desde SQL Server

Muy a menudo tenemos que utilizar los datos con ADODB y en este caso lo hacemos con la siguiente sintaxis:

Dim strSQL as String

strSQL = “SELECT COUNT(OrderID) AS Qty FROM tblOrders WHERE OfficeID = ” & TempVars!OfficeID

SQL Server no entiende TempVars, por lo tanto usted necesita utilizar la sintaxis anterior para poder ejecutar correctamente la cláusula WHERE.

Evite el uso excesivo de los filtro

Un método que yo nunca recomendaría es utilizar o confiar en filtros de datos dentro de formularios o informes. Es simplemente demasiado frágil e inseguro para ser considerado muy fiable.

Técnica # 2: Uso de views de SQL y SQL Inicios de sesión (Lo mejor para la separación)

La manera más favorable para evitar la corrupción de datos y no presentar datos a los usuarios no autorizados es mediante el uso del inicio de sesión en SQL Server, una tabla de usuario y una tercera tabla se encargan de hacer todo el filtrado del lado del servidor utilizando sólo los views de SQL, la aplicación nunca se conectara directamente a las tablas. Los views de SQL tendrían entonces unos criterios de filtro comunes, tales como:

CREATE VIEW dbo.vwCustomers AS
SELECT c.*
FROM dbo.tblCustomers AS c
INNER JOIN dbo.tblUsers AS u
  ON c.FranchiseID = u.FranchiseID
WHERE u.UserID = CURRENT_USER AND u.InUse = 1;

Usamos el  CURRENT_USER (una función integrada) que devolverá el nombre del usuario conectado. En este ejemplo, todos los usuarios que trabajen para una franquicia los vinculamos con los clientes a través de su FranchiseID. De este modo siempre se asegura que el usuario estará viendo una lista filtrada de la tabla de datos y no hay necesidad de realizar el filtrado en Access. Además, si la base de datos cae en las manos equivocadas y alguien abre el view vinculado no consigue nada, ya que no tiene un inicio de sesión de SQL Server y no se devuelven datos desde el servidor. También establecemos un InUse cuando un usuario ha iniciado sesión en la aplicación, lo que permite al sistema devolver datos sólo si el usuario ha iniciado sesión en la aplicación.

Tablas con enlaces: Nunca dejes sus datos sin esta protección

Si su base de datos incluye enlaces directos en las tablas de datos (algo para evitarlo casi por completo con una aplicación multiusuarios), y no lo añade o lo quita cuando se carga la aplicación o termina, Entonces, no hay protección o aislamiento de los datos de un usuario a otro. Cualquier programador experto de Access puede pasar las medidas de seguridad para conseguir las tablas y poner en peligro sus datos. O bien utilizar nuestra técnica de destruir enlaces DSN  (DSN-less)  o la metodología de Ben de no almacenar contraseñas .

Construcción de soluciones poderosas para múltiples empresas