Usando Servidor y embedded en la misma aplicación (2)

Deja un comentario

En un artículo anterior ya habíamos visto las ventajas de usar Servidor y embedded en la misma aplicación. Ahora veremos otro caso donde tal aprovechamiento puede resultar muy útil.

Escenario:

En un supermercado grande hay 40 cajas, de las cuales por lo menos 15 están constantemente trabajando. Normalmente esas cajas están conectadas a una Base de Datos mediante Cliente/Servidor y si todo funciona bien entonces es lo correcto porque todas las operaciones se realizan con rapidez.

Cada vez que se realiza una venta, se registran los datos de esa venta en una de las cajas y se insertan filas a las tablas respectivas de la Base de Datos. Todo bien hasta allí.

Sin embargo, ¿qué sucedería si por alguna razón se interrumpe la conexión de una (o varias, o todas) caja/s con el Servidor?

Escribir con papel y lápiz los datos de las ventas porque la conexión con el Servidor se cortó no es una opción en un supermercado que tiene mucha clientela.

¿Y entonces, qué hacemos?

Solución:

La solución es que si la aplicación detecta que se ha interrumpido la conexión con el Servidor entonces guarde los datos de las siguientes ventas en una Base de Datos local a la cual se conectará mediante embedded.

Así, ninguna venta se perderá, las cajas seguirán trabajando normalmente, y al final del turno, al final del día, o cuando se restablezca la conexión, los datos de las ventas que se habían insertado en la Base de Datos local serán transferidos a la Base de Datos remota.

Conclusión:

Que se corte la conexión entre una computadora y la Base de Datos que se encuentra en el Servidor no es frecuente pero puede ocurrir. Nuestra aplicación debe ser lo suficientemente inteligente como para prever esa posibilidad y actuar en consecuencia, de tal manera que esa interrupción de la conexión no cause trastornos a los usuarios.

La gran mayoría de los usuarios quizás ni se entere de que en cierto momento se interrumpió la conexión de su computadora con el Servidor porque siguieron trabajando normalmente, como si tal interrupción nunca hubiera ocurrido. Para ellos, todo fue normal.

Sin embargo, nuestra aplicación sí detectó que se interrumpió la conexión y entonces en la computadora de ese usuario automáticamente empezó a utilizar una Base de Datos alternativa, o auxiliar.

Cuando la conexión se restableció, o al final del turno del cajero, o al final del día, o cuando se decidió, todo lo que estaba en la Base de Datos alternativa se copió a la Base de Datos normal, la que se encuentra en el Servidor.

De esta manera, ninguna venta se perdió, y tampoco ningún dato se perdió.

Artículos relacionados:

Usando Servidor y embedded en la misma aplicación

El índice del blog Firebird21

El foro del blog Firebird21

Registrando los productos borrados

5 comentarios

Cuando se están cargando los datos de una venta el usuario (quizás cajero) va registrando ítem tras ítem los productos vendidos y la cantidad vendida.

¿Pero qué sucede si el cliente después de haberse hecho el registro decide que no va a llevar ese producto, quizás porque no tiene suficiente dinero?

Supongamos el caso de un supermercado: mientras se van registrando los productos vendidos y las cantidades vendidas, el cliente decide que no llevará uno de los productos. Normalmente en esos casos se llama al “Supervisor de cajas” o “Jefe del salón de ventas” quien introduce su clave de acceso con la cual se le permite borrar los productos no deseados por el cliente.

¿Pero cómo registramos esa acción en nuestras tablas de ventas?

Una posibilidad es guardar solamente los productos efectivamente vendidos. El problema con esto es que no quedarán registrados los productos que se borraron ¿Y es importante tenerlos registrados? Pues sí, porque eso le permitirá al Gerente o al propietario del supermercado detectar fácilmente y rápidamente todas las ventas donde se borraron productos. Si no tuvieran esa información entonces no podrían saber con cuanta frecuencia se borran productos, cuales son los productos que más se borran, quienes son los cajeros que más problemas tienen, etc.

Operativamente nuestra aplicación de ventas debería funcionar así:

  • Cuando se registra el primer producto vendido se imprime la cabecera de la Factura y los datos de ese primer producto
  • Cada vez que se registra un producto, se imprimen sus datos
  • Cuando se borra un producto, se imprimen sus datos
  • Cuando se cierra la venta, se imprimen los totales, los impuestos, y toda la demás información relevante

Alternativamente, se puede dejar la impresión de la Factura para el final, después de haberse cerrado la venta, pero siempre en ella deberían imprimirse los datos de los productos borrados.

Si una venta se cancela totalmente (quizás porque cuando iba a pagar el cliente se dio cuenta que no tenía dinero consigo), debe quedar registrada esa cancelación.

De esta manera TODO lo que se hizo en la computadora del cajero quedará registrado en nuestras tablas y podremos reconstruir lo que sucedió en ella, segundo a segundo.

Para poder conseguir esto último es requisito que una de las columnas de nuestra tabla de detalles de movimientos de ventas corresponda a la fecha y a la hora en la cual se registró la venta de ese producto.

Artículo relacionado:

El índice del blog Firebird21