Manejo de registros simultáneos.

[melina8050]

Buenos días a todos, mi problema es el siguiente:
En el sistema, los usuario pueden guardar en la base de datos registros de documentos, al mostrar el formulario al usuario se consulta en la BD el consecutivo siguiente, al momento de registrar también, pero si se da el caso que dos usuarios hagan el proceso al mismo tiempo y las dos consultas generen el mismo consecutivo ¿cómo se manejaría la prioridad del registro? ¿de que manera podría manejar éste evento para que no se registre dos veces el mismo consecutivo?

Algo como insertar sino existe, o no sé.

[huesos52]

melina no se si conozcas la existencia de las secuencias.

Este es un objeto que sirve para lo que dices. Es bastante estable. Si hay 2 o mas registros en el mismo microsegundo, pone los restantes en cola y los ejecuta uno tras otro.

Por ejemplo... cuando crea una tabla con "tipo de dato" serial, realmente estas creando una secuencia implicita en un campo integer.

me cuentas como te va.

saludos

[melina8050]

Pues los registros tienen una id que es serial con la secuencia como me dices, pero es que se necesita un numero del documento digitado, y como éstos consecutivos el usuario los puede configurar como anuales o mensuales, son de tipo de dato character varying porque pueden llevar guiones o letras, en php para mostrar ese consecutivo lo consulto y muestro el siguiente pero si dos personas abren el formulario al mismo tiempo les mostraría el mismo consecutivo, también se hace la consulta en el php que registra pero puede ser posible que dos personas lo hagan al tiempo y les daría la consulta el mismo consecutivo.

[cacr]

Puedes explicarte un poco mejor? el serial no tiene que ser visible para el usuario

[melina8050]

Lo que sucede es que el usuario puede configurar el consecutivo de sus documentos.

Como el usuario configura sus consecutivos para el número del documento éstos pueden tener letras o el guion.

Por ejemplo:

El usuario configuró sus recibos para que empiecen desde A1 y asi continúen. Al mostrar el formulario consulto el ultimo consecutivo y le muestro A2, pero si dos usuarios abren el formulario a los dos se les verá A2, al momento de registrar también se hace la consulta para saber el siguiente consecutivo que será A2, si ambos usuarios hacen el proceso al tiempo, la variable que lleva en consecutivo del documento será A2 y registraría dos veces este numero.

[huesos52]

Es muy mala practica hacer eso melina. Un consecutivo es ideal para identificar como registro unico una serie de datos. Pero no para utilizar este valor en operaciones diferentes y mucho menos para permitir al usuario interactuar con el. Como dice cacr.. el serial no tiene por que estar visible al usuario. Pienso que tu problema se relaciona mas con php que con postgresql.
Y n ultimas es un problema de visualización de los datos.

La verdad yo no te entiendo muy bien. Si crees que el problema tendría una solucion mas enfocada a postgresql, puedes ponernos un ejemplo mas grafico con el que te podamos ayudar..

saludos

[melina8050]

Ésta es mi tabla:

Código:

CREATE TABLE "public"."comprobante" (
"id" int4 DEFAULT nextval('comprobante_id_seq'::regclass) NOT NULL,
"num" varchar(20) NOT NULL,
"fecha" date NOT NULL,
"concepto" varchar(100) NOT NULL,
"tercero" int4 NOT NULL,
"estado" varchar(10) DEFAULT 'activo'::character varying NOT NULL,
"ureg" int4 NOT NULL,
"freg" time(6) NOT NULL
)

El campo num es configurable porque algunos números tienen prefijos con letras o con otro numero y un guion. El campo id lo usamos para hacer las modificaciones y demás cosas. Por ejemplo:

El usuario administrador de la empresa XYZ configura sus consecutivos como mensuales y señala que para el mes de enero el consecutivo empezara en 100.
En este caso los comprobantes se guardan con el prefijo del mes y el consecutivo.
Como el primer consecutivo es el 100 para guardar en la tabla seria $num = '01-100' Pero en el caso que dos usuarios digitadores estén trabajando y abran el formulario a los dos le mostrará que el siguiente consecutivo es 01-100 porque hasta ahora no está registrado. En caso que uno le de enviar primero que el otro, como el php que registra también pregunta por el consecutivo le mostrará al segundo un mesaje comunicándole que su comprobante se registró con 01-101 porque ya otro usuario registro el 01-100. Pero si los dos le dan enviar al tiempo, en el php que registra, la función traerá el mismo consecutivo y $num sera '01-100' para los dos usuarios. Y guardará en la tabla dos comprobantes 01-100.

Lo que quiero saber es si hay una manera de evitar esto en postgres.
No se si se podría con una secuencia teniendo en cuenta que estos consecutivos se pueden configurar.

Aclaro que el identificador de la tabla es id no num, éste campo contiene los numeros de los comprobantes según tengan configurado el consecutivo, porque son formas impresas que guardaran en el sistema, es como decir que guarden la factura FV505 o el comprobante A25-78.

[huesos52]

En caso que uno le de enviar primero que el otro, como el php que registra también pregunta por el consecutivo le mostrará al segundo un mesaje comunicándole que su comprobante se registró con 01-101 porque ya otro usuario registro el 01-100. Pero si los dos le dan enviar al tiempo, en el php que registra, la función traerá el mismo consecutivo y $num sera '01-100' para los dos usuarios. Y guardará en la tabla dos comprobantes 01-100.

Si te entendí bien, en php trae el 01-100 y lo muestra en los formularios de ambos usuarios. Si uno le da click primero, este se guarda sin problemas. Cuando el otro usuario (con 01-100) le da click, el sistema valida si este "num" ya se encuentra en la base de datos y lo guarda con el 01-101. Tu preocupación es si ambos usuarios le dan click en el mismo microsegundo la informacion que se guarde sea la misma y genere inconsistencia. Es así?

Si es así, una posible solución es poner el campo num de la tabla con una UNIQUE KEY. La cual impide datos repetidos en el campo de la tabla. Como esto es poco probable que pase en el mismo instante, lo que hará postgresql es generar una excepción y devolver un error de tipo (violate unique constraint) el cual puedes controlar desde php.

saludos

[melina8050]

Si así es, ya lo implemente y probé y todo muy bien.

Muchas Gracias.

[cacr]

Ya se que no es mi problema, pero para qué querría alguien ir poniéndo su propio correlativo? un código del tipo asd-2345-afsf-xxx es facilmente programable en postgresql y seguiría siendo un correlativo del tipo "serial"

En fin... ya lo solucionaste!