Evitar que un usuario se conecte dos veces
 

En un BB.DD. con FB 2.5.6 quiero implementar un sistema para qu el mismo usuario no pueda conectarse desde dos puestos diferentes de forma simultánea. He estado dando vueltas por ahí y en el blog Firebird SQL encontré este código que usa una tabla y dos triggers:

Código SQL [-]
CREATE TABLE CONEXION (
  CON_IDENTI INTEGER NOT NULL,
  CON_IDECON INTEGER NOT NULL,
  CON_NOMBRE VARCHAR(15) CHARACTER SET ISO8859_1 NOT NULL COLLATE ES_ES_CI_AI,
  CON_TIMEST TIMESTAMP);

ALTER TABLE CONEXION ADD CONSTRAINT PK_CONEXION PRIMARY KEY (CON_IDENTI);

ALTER TABLE CONEXION ADD CONSTRAINT UQ_CONEXION UNIQUE (CON_NOMBRE);

Al conectarse a la BB.DD.:

Código SQL [-]
CREATE TRIGGER CONECTADO
ACTIVE ON 
  CONNECT
POSITION 2
AS
BEGIN

   -- Primero, se borran las filas de los usuarios que no estan conectados
   -- pero aparecen como conectados
    DELETE FROM Conexion
     WHERE CON_IDECON NOT IN (SELECT MON$ATTACHMENT_ID FROM MON$ATTACHMENTS);

   -- Segundo, se trata de insertar una fila a la tabla CONEXION.
   -- Como la tabla CONEXION tiene una restriccion UNIQUE KEY, un usuario
   -- no se podra conectar mas de una vez al mismo tiempo
    INSERT INTO Conexion (CON_IDENTI, CON_IDECON, CON_NOMBRE, CON_TIMEST)
                  VALUES (0, CURRENT_CONNECTION, CURRENT_USER, CURRENT_TIMESTAMP);
END

Al desconectarse

Código SQL [-]
CREATE TRIGGER DESCONECTADO
ACTIVE ON 
  DISCONNECT
POSITION 1
AS
BEGIN
   DELETE FROM Conexion WHERE Con_Nombre = CURRENT_USER;
END

Si entro una primera vez con un usuario, al tabla CONEXION queda así:


Si ahora accedo con un segundo usuario, sin cerrar la sesión anterior, la tabla queda así:


Sin embargo, si sin cerrar ninguna de las dos sesiones hago un SELECT sobre la tabla MON$ATTACHMENTS se muestra esto:

Como se puede ver ambos usaurios están activos pero en la tabla CONEXION sólo se muestra el que ha entrado último. ¿Alguien me puede explicar la razón? No acabo de entender que puede estar pasando.

No recuerdo bien cómo iba esa tabla, pero parece que están conectados 3 ususarios: sysdba, juani y angel.
Hay otro sysdba que no está conectado (o está inactivo), mon$state=0 y los demás están en con el valor 1.

Que alocada razón hay para imponer tal restricción?

Uno de los sydba aparece porque las capturas de pantalla están hechas con SQLManager; imagino que será el que aparece como activo. Lo que sí me has dado una pista interesante que tengo que probar y es comprobar el estado del usuario.
¿Y que sentido tiene que el mismo usuario pueda abrir sesión en dos puestos diferentes? Lo entiendo como medida de seguridad.

¡Era demasiado fácil! He modificado el trigger así:

Código SQL [-]
CREATE TRIGGER CONECTADO
ACTIVE ON 
  CONNECT
POSITION 2
AS
BEGIN

   -- Primero, se borran las filas de los usuarios que no estan conectados
   -- pero aparecen como conectados
    DELETE FROM Conexion
     WHERE CON_IDECON NOT IN (SELECT MON$ATTACHMENT_ID FROM MON$ATTACHMENTS WHERE MON$STATE = 1);

   -- Segundo, se trata de insertar una fila a la tabla CONEXION.
   -- Como la tabla CONEXION tiene una restriccion UNIQUE KEY, un usuario
   -- no se podra conectar mas de una vez al mismo tiempo
    INSERT INTO Conexion (CON_IDENTI, CON_IDECON, CON_NOMBRE, CON_TIMEST)
                  VALUES (0, CURRENT_CONNECTION, CURRENT_USER, CURRENT_TIMESTAMP);
END

En teoría así sólo borraría aquellas filas de la tabla Conexion que en MON$ATTACHMENTS estuvieran con estado 0 ya que eso significaría que el usuario está inactivo. Pero no, sigue borrando la fila del usuario ANGEL a pesar de que no debería. Sin embargo, si ejecuto ese trozo del trigger (DELETE) desde SQLManager no borra ninguna entrada. CAda vez lo entiendo menos.

He estado hacienod algunas pruebas con SQLManager y he llegado a la conclusión que aparece un usuario sysdba por cada pestaña que se tiene abierta y otro más (que ha de ser el mon$state=0) que corresponde al propio SQLManager.

Mira si te sirve esto.

Gracias por la sugerencia. El problema que veo yo, y no me explico, es por qué funciona distinto ese DELETE FROM si está dentro o fuera del trigger ya que como he comentado: si se ejecuta dentro del trigger borra todas las filas que haya independientemente del estado; si se ejecuta fuera deja las que están activas. Veo que la solución pasa por ejecutar el DELETE antes de que se lance el trigger.