Re: problema orden comprobación integridad

Respecto al problema q planteaba fue un error al copiar la sentencia q fallaba
en mi maquina local al hacer la prueba, pero lo que me preguntas es porque la
solución de replicacion que utilizo tiene un mecanismo de fallback que cuando el
registro (identificado por la clave primaria) ya existe pasa los mismos valores
del insert que lleva como un update para esa clave primaria, sin embargo si
salta un error de integridad por indice único no lo hace. El problema aquí es
que la base de datos donde se crea por primera vez el registro graba (mediante
un trigger) los cambios, los envía a la central y la central lo envía de nuevo a
todos los nodos (entre los cuales esta el de origen), por eso tiene el mecanismo
de cambiar a update si la clave primaria existe porque cuando quieres que lo que
grabes en cada nodo se replique a los demás y no solamente al central, la misma
sentencia que creo la fila te vuelve luego.

postgres Emanuel CALVO FRANCO escribió:
> CONSTRAINT albaran_salida_bultos_cab_pkey PRIMARY KEY (bulto_id),
> CONSTRAINT bulto_cabecera_id_documento_key UNIQUE (id_documento,
> numero_bulto_documento)
>
> (...) error de clave primaria el callback, como aquí el error es un
> indice único me bloquea los canales de replicacion con un error, por
> que sucede esto? puedo hacer q siempre salte el error sobre la clave
> primaria sin borrar el indice único? (...)
>
> Entonces para que tenes los constratints si desoueslos queres saltear?
> Por lo que estoy viendo vas a tener que normalizar a un nivel superior
> para tener dos tablas.
>
>
>
>
> El día 3 de octubre de 2008 6:22, Oswaldo Hernández
> <listas(at)soft-com(dot)es> escribió:
>> Linos escribió:
>>> Moises Alberto Lindo Gutarra escribió:
>>>> El día 2 de octubre de 2008 16:54, Linos <info(at)linos(dot)es> escribió:
>> ...
>>>>>>> skuda=# INSERT INTO bulto_cabecera(id_documento, bulto_id,
>>>>>>> numero_bulto_documento, time_stamp, id_usuario, completo, tipo_origen)
>>>>>>> VALUES ('2000244341'::integer, '2000244343'::integer, '2'::integer,
>>>>>>> 'now()'::timestamp with time zone, '2102'::integer, FALSE::boolean,
>>>>>>> 'ALBARAN_SALIDA'::text)
>>>>>>> skuda-# ;
>>>>>>> ERROR: duplicate key value violates unique constraint
>>>>>>> "albaran_salida_bultos_cab_pkey"
>>>>>>> skuda=# \q
>> ...
>>>>>>> skuda=# INSERT INTO skuda.bulto_cabecera(id_documento, bulto_id,
>>>>>>> numero_bulto_documento, time_stamp, id_usuario, completo, tipo_origen)
>>>>>>> VALUES ('2000244341'::integer, '200024434'::integer, '2'::integer,
>>>>>>> 'now()'::timestamp with time zone, '2102'::integer, FALSE::boolean,
>>>>>>> 'ALBARAN_SALIDA'::text);
>>>>>>> ERROR: duplicate key value violates unique constraint
>>>>>>> "bulto_cabecera_id_documento_key"
>>>>>>>
>> ...
>>> si es normal q esto suceda así (que de manera random o eso parece elija
>>> con que constraint negar la inserción de la nueva fila)
>>>
>> Linos,
>>
>> He hecho una sencilla prueba y *siempre* salta la excepcion de la pk aunque
>> tambien haya duplicidad en la clave única.
>>
>> En los insert que envias estas utilizándo un valor distinto para la primary
>> key. ¿Estas Seguro de que el bulto_id '200024434' existe?
>>
>> --
>> *****************************************
>> Oswaldo Hernández
>> oswaldo (@) soft-com (.) es
>> *****************************************
>> PD:
>> Antes de imprimir este mensaje, asegúrese de que es necesario.
>> El medio ambiente está en nuestra mano.
>> --
>> TIP 7: no olvides aumentar la configuración del "free space map"
>>
> --
> TIP 7: no olvides aumentar la configuración del "free space map"