Replicación Transaccional Campo identity

Para comenplementar mejor la idea les explico que se desea realizar:
Como no pueden implementar alta disponibilidad usando clustering (por
costos) o log shipping (por no tener sql enterprise) se está usando la
replicación de sqlserver de forma transaccional para que todo cambio sea
pasado a otro equipo de forma inmediata (insert, delete, update) sin embargo
hay cierta peculiaridad que una o varias de las tablas que se desean replicar
usan campos de este tipo identity y que a su vez son primary key de las
mismas el detalle es que se desea realizar una replicación del publicador a
dos suscriptores pero si por a o b motivo falla el publicador se usaria
cualquiera de los otros dos para que sea el servidor principal y las
aplicaciones sigan funcionando, evidentemente la replicación ya no porque
murio el padre (publicador, distribuidor) pero tengo el detalle de que al
momento de hacer la replicacion de manera simple no pasa el tipo identity al
suscriptor más sino solo su tipo de dato base, como hago entonces para
aplicar mi contingencia, tendría que correr un script donde habilite el hecho
de que esos campos sean identity??? Por favor su ayuda y comentarios, yo sé
que es complejo hacerlo por replicación y este no es su objetivo, alta
disponibilidad, pero por el momento se lo debe visualizar así. Sobre estas
condiciones su ayuda.
Muchas gracias.


"Pao" wrote:

Hola.
Necesitaba aclarar una duda conceptual:
Cuando tengo una o varias tablas que deseo replicar pero las mismas usan
campos del tipo identity y que a la ve son primary key tengo problemas o debo
considerar ciertas cuestiones si deseo realizar:
* Puedo hacer replicacion transaccional bidireccional; de un publicador a
varios suscriptores y esto a él? es posible si tengo una columna de este
tipo? Como puedo hacerlo o que contras tengo para ello?
* Puedo hacer replicacion transacional unidireccional; de un publicador a
varios suscriptores? De lo que revisé de forma nativa me sale una advertencia
que indica que en el lado del suscriptor me va a crear la table pero el campo
no lo define como identityQue cosas más se deben considerar????

Pao,

Durante el proceso de seteo de la replicacion, sql server te dice los pasos
a seguir cuando replicas tablas donde la pk es identity, esto esta en la
misma pantalla "Articles Issues". Aca expongo el texto de esa pantalla (copy
and paste), y espero no estar infringiendo los derechos reservados de
Microsoft, al menos no es esa mi intencion.

*****
Because this publication does not allow updatable subscriptions, when
IDENTITY columns are transferred to the Subscriber, the IDENTITY property
will not be transferred. (For example, a column defined as INT IDENTITY at
the Publisher will be defined as INT at the Subscriber.)

If you want the IDENTITY property transferred to the subscription table, you
must do the following:

» Create the subscription table manually using the IDENTITY property
and the NOT FOR REPLICATION option. You can have SQL Server execute a custom
script to perform this action before the snapshot is applied. To specify a
custom script, create the publication, create the script, and enter the
script name on the Snapshot tab of the publication properties.

» Set the name conflicts article property so that SQL Server does not
drop an existing table when applying the snapshot at the Subscriber. This
property is on the Snapshot tab of article properties.
*****


AMB

"Pao" wrote:

Para comenplementar mejor la idea les explico que se desea realizar:
Como no pueden implementar alta disponibilidad usando clustering (por
costos) o log shipping (por no tener sql enterprise) se está usando la
replicación de sqlserver de forma transaccional para que todo cambio sea
pasado a otro equipo de forma inmediata (insert, delete, update) sin embargo
hay cierta peculiaridad que una o varias de las tablas que se desean replicar
usan campos de este tipo identity y que a su vez son primary key de las
mismas el detalle es que se desea realizar una replicación del publicador a
dos suscriptores pero si por a o b motivo falla el publicador se usaria
cualquiera de los otros dos para que sea el servidor principal y las
aplicaciones sigan funcionando, evidentemente la replicación ya no porque
murio el padre (publicador, distribuidor) pero tengo el detalle de que al
momento de hacer la replicacion de manera simple no pasa el tipo identity al
suscriptor más sino solo su tipo de dato base, como hago entonces para
aplicar mi contingencia, tendría que correr un script donde habilite el hecho
de que esos campos sean identity??? Por favor su ayuda y comentarios, yo sé
que es complejo hacerlo por replicación y este no es su objetivo, alta
disponibilidad, pero por el momento se lo debe visualizar así. Sobre estas
condiciones su ayuda.
Muchas gracias.


"Pao" wrote:

> Hola.
> Necesitaba aclarar una duda conceptual:
> Cuando tengo una o varias tablas que deseo replicar pero las mismas usan
> campos del tipo identity y que a la ve son primary key tengo problemas o debo
> considerar ciertas cuestiones si deseo realizar:
> * Puedo hacer replicacion transaccional bidireccional; de un publicador a
> varios suscriptores y esto a él? es posible si tengo una columna de este
> tipo? Como puedo hacerlo o que contras tengo para ello?
> * Puedo hacer replicacion transacional unidireccional; de un publicador a
> varios suscriptores? De lo que revisé de forma nativa me sale una advertencia
> que indica que en el lado del suscriptor me va a crear la table pero el campo
> no lo define como identityQue cosas más se deben considerar????

INF: How to Set Up an Identity Column on both the Publisher and the
Subscriber with Transactional Replication
http://support.microsoft.com/defaul...-us;300164


AMB

"Pao" wrote:

Para comenplementar mejor la idea les explico que se desea realizar:
Como no pueden implementar alta disponibilidad usando clustering (por
costos) o log shipping (por no tener sql enterprise) se está usando la
replicación de sqlserver de forma transaccional para que todo cambio sea
pasado a otro equipo de forma inmediata (insert, delete, update) sin embargo
hay cierta peculiaridad que una o varias de las tablas que se desean replicar
usan campos de este tipo identity y que a su vez son primary key de las
mismas el detalle es que se desea realizar una replicación del publicador a
dos suscriptores pero si por a o b motivo falla el publicador se usaria
cualquiera de los otros dos para que sea el servidor principal y las
aplicaciones sigan funcionando, evidentemente la replicación ya no porque
murio el padre (publicador, distribuidor) pero tengo el detalle de que al
momento de hacer la replicacion de manera simple no pasa el tipo identity al
suscriptor más sino solo su tipo de dato base, como hago entonces para
aplicar mi contingencia, tendría que correr un script donde habilite el hecho
de que esos campos sean identity??? Por favor su ayuda y comentarios, yo sé
que es complejo hacerlo por replicación y este no es su objetivo, alta
disponibilidad, pero por el momento se lo debe visualizar así. Sobre estas
condiciones su ayuda.
Muchas gracias.


"Pao" wrote:

> Hola.
> Necesitaba aclarar una duda conceptual:
> Cuando tengo una o varias tablas que deseo replicar pero las mismas usan
> campos del tipo identity y que a la ve son primary key tengo problemas o debo
> considerar ciertas cuestiones si deseo realizar:
> * Puedo hacer replicacion transaccional bidireccional; de un publicador a
> varios suscriptores y esto a él? es posible si tengo una columna de este
> tipo? Como puedo hacerlo o que contras tengo para ello?
> * Puedo hacer replicacion transacional unidireccional; de un publicador a
> varios suscriptores? De lo que revisé de forma nativa me sale una advertencia
> que indica que en el lado del suscriptor me va a crear la table pero el campo
> no lo define como identityQue cosas más se deben considerar????

Disculpa que te moleste una vez más pero podrías explicarlo con tus palabras
porque me confunde un poco el ingles a más de que estos conceptos son nuevos
para mi.
Al igual que el articulo entiendo como que si se lo puede hacer aunque MS
recomienda que uses merge, pero si no es posible te dan una opción pero igual
no me es clara lo que me dicen.
Gracias por tu tiempo y molestia.

"Alejandro Mesa" wrote:

Pao,

Durante el proceso de seteo de la replicacion, sql server te dice los pasos
a seguir cuando replicas tablas donde la pk es identity, esto esta en la
misma pantalla "Articles Issues". Aca expongo el texto de esa pantalla (copy
and paste), y espero no estar infringiendo los derechos reservados de
Microsoft, al menos no es esa mi intencion.

*****
Because this publication does not allow updatable subscriptions, when
IDENTITY columns are transferred to the Subscriber, the IDENTITY property
will not be transferred. (For example, a column defined as INT IDENTITY at
the Publisher will be defined as INT at the Subscriber.)

If you want the IDENTITY property transferred to the subscription table, you
must do the following:

» Create the subscription table manually using the IDENTITY property
and the NOT FOR REPLICATION option. You can have SQL Server execute a custom
script to perform this action before the snapshot is applied. To specify a
custom script, create the publication, create the script, and enter the
script name on the Snapshot tab of the publication properties.

» Set the name conflicts article property so that SQL Server does not
drop an existing table when applying the snapshot at the Subscriber. This
property is on the Snapshot tab of article properties.
*****


AMB

"Pao" wrote:

> Para comenplementar mejor la idea les explico que se desea realizar:
> Como no pueden implementar alta disponibilidad usando clustering (por
> costos) o log shipping (por no tener sql enterprise) se está usando la
> replicación de sqlserver de forma transaccional para que todo cambio sea
> pasado a otro equipo de forma inmediata (insert, delete, update) sin embargo
> hay cierta peculiaridad que una o varias de las tablas que se desean replicar
> usan campos de este tipo identity y que a su vez son primary key de las
> mismas el detalle es que se desea realizar una replicación del publicador a
> dos suscriptores pero si por a o b motivo falla el publicador se usaria
> cualquiera de los otros dos para que sea el servidor principal y las
> aplicaciones sigan funcionando, evidentemente la replicación ya no porque
> murio el padre (publicador, distribuidor) pero tengo el detalle de que al
> momento de hacer la replicacion de manera simple no pasa el tipo identity al
> suscriptor más sino solo su tipo de dato base, como hago entonces para
> aplicar mi contingencia, tendría que correr un script donde habilite el hecho
> de que esos campos sean identity??? Por favor su ayuda y comentarios, yo sé
> que es complejo hacerlo por replicación y este no es su objetivo, alta
> disponibilidad, pero por el momento se lo debe visualizar así. Sobre estas
> condiciones su ayuda.
> Muchas gracias.
>
>
> "Pao" wrote:
>
> > Hola.
> > Necesitaba aclarar una duda conceptual:
> > Cuando tengo una o varias tablas que deseo replicar pero las mismas usan
> > campos del tipo identity y que a la ve son primary key tengo problemas o debo
> > considerar ciertas cuestiones si deseo realizar:
> > * Puedo hacer replicacion transaccional bidireccional; de un publicador a
> > varios suscriptores y esto a él? es posible si tengo una columna de este
> > tipo? Como puedo hacerlo o que contras tengo para ello?
> > * Puedo hacer replicacion transacional unidireccional; de un publicador a
> > varios suscriptores? De lo que revisé de forma nativa me sale una advertencia
> > que indica que en el lado del suscriptor me va a crear la table pero el campo
> > no lo define como identityQue cosas más se deben considerar????