ok!
El día 3 de octubre de 2008 15:09, Linos <[EMAIL PROTECTED]> escribió:
> 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
>> <[EMAIL PROTECTED]> escribió:
>>>
>>> Linos escribió:
>>>>
>>>> Moises Alberto Lindo Gutarra escribió:
>>>>>
>>>>> El día 2 de octubre de 2008 16:54, Linos <[EMAIL PROTECTED]> 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"
>
>
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
http://archives.postgresql.org/pgsql-es-ayuda
