Problema con claves en replicacion

Hola, no me quedo claro si estas o no usando replicacion desde SQLServer o
bien desde la aplicacion


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


escribió en el mensaje
news:
Hola,os comento mi problema

Tengo un servidor "Central" que reparte trabajos a las distintas
"Sucursales"

A la hora de repartir los datos no hay problema , ya que localmente en
cada sucursal se intentara que no se trabaje nada mas que con los datos
de la central , asi todo he separado los datos de uno y de otro para
que no se solapen ( en local los ids son pares, y en la central
impares)

El problema me viene porque si yo envio un "trabajo" a la sucursal ,
esta , a fin de relizar ese trabajo insertara filas nuevas en las
tablas relacionadas al trabajo . Una vez se suba el trabajo a la
central , esas nuevas filas entraran en conflicto con las de otras
sucursales.A ver si con un ejemplo se ve mejor


Central -> envia el trabajo 1 -> Sucursal A
Central -> envia el trabajo 3 -> Sucursal B

Sucursal A crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Sucursal B crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Al subir los datos a la central , en esa tabla relacionada ,llegaran
dos registros con id numero 1

¿Existe alguna solucion viable para solventar esto? . Tanto en la
central como en las sucursales se trabaja con una aplicacion ya
realizada en la que no estaba previsto realizar estas tareas de
replicacion , cno lo que cuantos menos cambios realize en la base de
datos , menos tendre que tocar la aplicacion (lo digo mas que nada por
la posible solucion de eliminar los campos identity)

Gracias

En principio he creado un apartado en el que realizo la sincronización
mediante SQLDMO desde la aplicacion. Supongo que sea igual que
realizarlo de las otras formas,pero en cualquier caso no me importaria
hacerlo finalmente desde el sql server , o bien desde el administrador
de sincronización de windows,o como sea.


Maxi ha escrito:

Hola, no me quedo claro si estas o no usando replicacion desde SQLServer o
bien desde la aplicacion


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


escribió en el mensaje
news:
Hola,os comento mi problema

Tengo un servidor "Central" que reparte trabajos a las distintas
"Sucursales"

A la hora de repartir los datos no hay problema , ya que localmente en
cada sucursal se intentara que no se trabaje nada mas que con los datos
de la central , asi todo he separado los datos de uno y de otro para
que no se solapen ( en local los ids son pares, y en la central
impares)

El problema me viene porque si yo envio un "trabajo" a la sucursal ,
esta , a fin de relizar ese trabajo insertara filas nuevas en las
tablas relacionadas al trabajo . Una vez se suba el trabajo a la
central , esas nuevas filas entraran en conflicto con las de otras
sucursales.A ver si con un ejemplo se ve mejor


Central -> envia el trabajo 1 -> Sucursal A
Central -> envia el trabajo 3 -> Sucursal B

Sucursal A crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Sucursal B crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Al subir los datos a la central , en esa tabla relacionada ,llegaran
dos registros con id numero 1

¿Existe alguna solucion viable para solventar esto? . Tanto en la
central como en las sucursales se trabaja con una aplicacion ya
realizada en la que no estaba previsto realizar estas tareas de
replicacion , cno lo que cuantos menos cambios realize en la base de
datos , menos tendre que tocar la aplicacion (lo digo mas que nada por
la posible solucion de eliminar los campos identity)

Gracias

Hola, te recomiendo que leas en tus libros on line sobre "replicacion" en
español esta como duplicacion, sobre todo la opcion de Mezcla


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


escribió en el mensaje
news:

En principio he creado un apartado en el que realizo la sincronización
mediante SQLDMO desde la aplicacion. Supongo que sea igual que
realizarlo de las otras formas,pero en cualquier caso no me importaria
hacerlo finalmente desde el sql server , o bien desde el administrador
de sincronización de windows,o como sea.


Maxi ha escrito:

Hola, no me quedo claro si estas o no usando replicacion desde SQLServer o
bien desde la aplicacion


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


escribió en el mensaje
news:
Hola,os comento mi problema

Tengo un servidor "Central" que reparte trabajos a las distintas
"Sucursales"

A la hora de repartir los datos no hay problema , ya que localmente en
cada sucursal se intentara que no se trabaje nada mas que con los datos
de la central , asi todo he separado los datos de uno y de otro para
que no se solapen ( en local los ids son pares, y en la central
impares)

El problema me viene porque si yo envio un "trabajo" a la sucursal ,
esta , a fin de relizar ese trabajo insertara filas nuevas en las
tablas relacionadas al trabajo . Una vez se suba el trabajo a la
central , esas nuevas filas entraran en conflicto con las de otras
sucursales.A ver si con un ejemplo se ve mejor


Central -> envia el trabajo 1 -> Sucursal A
Central -> envia el trabajo 3 -> Sucursal B

Sucursal A crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Sucursal B crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Al subir los datos a la central , en esa tabla relacionada ,llegaran
dos registros con id numero 1

¿Existe alguna solucion viable para solventar esto? . Tanto en la
central como en las sucursales se trabaja con una aplicacion ya
realizada en la que no estaba previsto realizar estas tareas de
replicacion , cno lo que cuantos menos cambios realize en la base de
datos , menos tendre que tocar la aplicacion (lo digo mas que nada por
la posible solucion de eliminar los campos identity)

Gracias

Gracias Jorge , te comento :

La idea de añadir un campo sucursal fue lo primero que pense,pero sin
darle muchas vueltas la descarte por tener que cambiar la aplicacion
(sobre todo al tener que eliminar la opcion de autoincremento de los
identitys)

La solución de los seeds la habia tenido en cuenta, pero la descarte
por lo que me comentas de que suele ser propensa a errores ( y mas que
nada , a lo problematico de la forma de solucionarlos) . Tampoco me
parecia una solución del todo idonea ni comoda , aunque no la descarto
completamente.

Lo valorare mas detenidamente si no existe otra solución.

El diseño no tiene en cuenta la replicación porque en un principio
esta aplicacion no estaba pensada ni remotamente para utilizarse en
varias sucursales

Gracias




Jorge Gonzalez ha escrito:

Estimado José Foros

Replicación es un tema complejo. No solamente conlleva la configuración del
Servidor SQL para que replique tablas, hay todo un diseño que hacer sobre el
rendimiento de los servidores, carga de trabajo (workload), peso de las
transacciones, etc, pero sobre todo, un tema de suma importancia es el tema
de que el diseño de los datos debe tomar en cuenta que los datos serán
replicados. Es decir, que cuando construis el diseño de tablas, tenés que
pensar que esas tablas serán replicadas para luego evitar problemas como el
tuyo. Yo he implementado con éxito 2 soluciones a tu problema:

1. Incluís un campo IdSucursal a cada tabla que puede contener datos
propios. Este campo debe ser parte de la llave primaria. Posiblemente pueda
tener un valor por defecto en cada instalación de forma que tu aplicación no
tenga que hacerse cargo de insertarlo cada vez. Así podés tener un campo
Identity como parte de la clave que no será duplicado en la llave primaria
ya que esta incluye el campo IdSucursal. Esto aplica a todas las tablas de
la base de datos que serán replicadas. Esta solución implica cambios
importantes en la aplicación. Pero es al final, más óptima y te evitará
problemas en el futuro.

2. A cada instalación le designás un rango de valores posibles para los
Identity. Por ejemplo, la sucursal 1 usará Identity del 1 al 10 millones, la
sucursal 2 usará del 10,000,001 al 20,000,000 y así sucesivamente. Esta es
una solución funcional ya que al centralizar la información los Identity no
se traslaparán. Toma en cuenta que para estoy hay que marcar los Identity en
la base de datos central como NOT FOR REPLICATION. Además el nivel de
control sobre los SEED de los Identity es bien difícil ya que cualquier
error te puede causar estragos. Esta solución o implica ningún cambio en tu
aplicación, pero es propensa a problemas y además tenés que hacer cambios en
las bases de datos, en los SEED de los Identity.

Creo que vos vas a pagar el precio de no haber hecho el diseño tomando en
cuenta la replicación. Que es un precio alto. De acuerdo a mi experiencia
esas son las 2 posible soluciones y las 2 implican cambios importantes en
mayor o menor grado.

Si alguien conoce alguna solución menos compleja, será interesante
escucharla.

saludos
Jorge González
escribió en el mensaje
news:
Hola,os comento mi problema

Tengo un servidor "Central" que reparte trabajos a las distintas
"Sucursales"

A la hora de repartir los datos no hay problema , ya que localmente en
cada sucursal se intentara que no se trabaje nada mas que con los datos
de la central , asi todo he separado los datos de uno y de otro para
que no se solapen ( en local los ids son pares, y en la central
impares)

El problema me viene porque si yo envio un "trabajo" a la sucursal ,
esta , a fin de relizar ese trabajo insertara filas nuevas en las
tablas relacionadas al trabajo . Una vez se suba el trabajo a la
central , esas nuevas filas entraran en conflicto con las de otras
sucursales.A ver si con un ejemplo se ve mejor


Central -> envia el trabajo 1 -> Sucursal A
Central -> envia el trabajo 3 -> Sucursal B

Sucursal A crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Sucursal B crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Al subir los datos a la central , en esa tabla relacionada ,llegaran
dos registros con id numero 1

¿Existe alguna solucion viable para solventar esto? . Tanto en la
central como en las sucursales se trabaja con una aplicacion ya
realizada en la que no estaba previsto realizar estas tareas de
replicacion , cno lo que cuantos menos cambios realize en la base de
datos , menos tendre que tocar la aplicacion (lo digo mas que nada por
la posible solucion de eliminar los campos identity)

Gracias

Estimado José Foros

Replicación es un tema complejo. No solamente conlleva la configuración del
Servidor SQL para que replique tablas, hay todo un diseño que hacer sobre el
rendimiento de los servidores, carga de trabajo (workload), peso de las
transacciones, etc, pero sobre todo, un tema de suma importancia es el tema
de que el diseño de los datos debe tomar en cuenta que los datos serán
replicados. Es decir, que cuando construis el diseño de tablas, tenés que
pensar que esas tablas serán replicadas para luego evitar problemas como el
tuyo. Yo he implementado con éxito 2 soluciones a tu problema:

1. Incluís un campo IdSucursal a cada tabla que puede contener datos
propios. Este campo debe ser parte de la llave primaria. Posiblemente pueda
tener un valor por defecto en cada instalación de forma que tu aplicación no
tenga que hacerse cargo de insertarlo cada vez. Así podés tener un campo
Identity como parte de la clave que no será duplicado en la llave primaria
ya que esta incluye el campo IdSucursal. Esto aplica a todas las tablas de
la base de datos que serán replicadas. Esta solución implica cambios
importantes en la aplicación. Pero es al final, más óptima y te evitará
problemas en el futuro.

2. A cada instalación le designás un rango de valores posibles para los
Identity. Por ejemplo, la sucursal 1 usará Identity del 1 al 10 millones, la
sucursal 2 usará del 10,000,001 al 20,000,000 y así sucesivamente. Esta es
una solución funcional ya que al centralizar la información los Identity no
se traslaparán. Toma en cuenta que para estoy hay que marcar los Identity en
la base de datos central como NOT FOR REPLICATION. Además el nivel de
control sobre los SEED de los Identity es bien difícil ya que cualquier
error te puede causar estragos. Esta solución o implica ningún cambio en tu
aplicación, pero es propensa a problemas y además tenés que hacer cambios en
las bases de datos, en los SEED de los Identity.

Creo que vos vas a pagar el precio de no haber hecho el diseño tomando en
cuenta la replicación. Que es un precio alto. De acuerdo a mi experiencia
esas son las 2 posible soluciones y las 2 implican cambios importantes en
mayor o menor grado.

Si alguien conoce alguna solución menos compleja, será interesante
escucharla.

saludos
Jorge González
escribió en el mensaje
news:
Hola,os comento mi problema

Tengo un servidor "Central" que reparte trabajos a las distintas
"Sucursales"

A la hora de repartir los datos no hay problema , ya que localmente en
cada sucursal se intentara que no se trabaje nada mas que con los datos
de la central , asi todo he separado los datos de uno y de otro para
que no se solapen ( en local los ids son pares, y en la central
impares)

El problema me viene porque si yo envio un "trabajo" a la sucursal ,
esta , a fin de relizar ese trabajo insertara filas nuevas en las
tablas relacionadas al trabajo . Una vez se suba el trabajo a la
central , esas nuevas filas entraran en conflicto con las de otras
sucursales.A ver si con un ejemplo se ve mejor


Central -> envia el trabajo 1 -> Sucursal A
Central -> envia el trabajo 3 -> Sucursal B

Sucursal A crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Sucursal B crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Al subir los datos a la central , en esa tabla relacionada ,llegaran
dos registros con id numero 1

¿Existe alguna solucion viable para solventar esto? . Tanto en la
central como en las sucursales se trabaja con una aplicacion ya
realizada en la que no estaba previsto realizar estas tareas de
replicacion , cno lo que cuantos menos cambios realize en la base de
datos , menos tendre que tocar la aplicacion (lo digo mas que nada por
la posible solucion de eliminar los campos identity)

Gracias