SQL - Replication.

Estoy haciendo una replicacion de una base de datos como transaccional, y hago la publicacion de las tablas seleccionadas.
- El snapshot se completa bien o SUCCEEDED.
- El agente de replicacion me da un error.

Este me dice que un alter table tubo un conflicto con un foreign key constraint, en el subscritor, y el numero del error es el 547.

No he hecho ningun alter table, ya que fue el proceso seguido a terminar de crear la publicacion. Y fisicamente, no he hecho ninguna modificacion a la tabla en la base de datos publicada, o en la BD suscrita.

el monitor siempre me esta dando un error, ya que al excluir esta tabla, me saldra otra mas con el mismo problema.

¿Nos puedes enviar el TEXTO INTEGRO del error?

Te informo, que esta tabla no tiene key duplicados, ya que tiene un constraint que lo impide. Intente, quitandole las relaciones de integridad a la publicacion, pero no funciono. Por el momento, estoy haciendo la replicacion de esta tabla solamente, aislando todos los demas problemas que pudiese encontrar. Esta compuesta de un identity, un timestamp, una PK caracter, y el resto char y money.

Investigue en msdn, encontrando un error casi identico, y decia que se resolvia con el sp3 de sql, le he instalado el sp4, que tiene todos los SP anteriores acumulados. Aun persiste el problema, por lo que creo, que debe ser algo que estoy haciendo mal. Seguire investigando, de antemano, gracias por la ayuda que puedas ofrecerme.

Este es el error que me informa el agente, el anterior no pude reproducirlo.

Cannot insert duplicate key row in object 'vehiculos' with unique index 'PK_vehiculos'.
(Source: DSK-DES-04 (Data source); Error number: 2601)
---------------------------------------------------------------------------------------------------------------
Function sequence error
(Source: ODBC SQL Server Driver (ODBC); Error number: S1010)
---------------------------------------------------------------------------------------------------------------

¿Porque NO le crees a SQL Server que estas tratando de INSERTAR registros DUPLICADOS por la primary key "PK_vehiculos"?

Porque hice un query buscando esos duplicados de la tabla origen, en donde no encontre ninguno.

Busque por el codigo completo del PK, luego, al no tener resultados, pense en que podia ser que estubieran varios nulos, o que 1 espacio fuera igual que 2 espacios.

Sin resultados.

No creo qeu tenga registros exactamente iguales, gracias a la columna identidad, que cambia automaticamente. Ademas, al insertar los registros, PK_VEHICULO, impide que se inserten duplicados.

Ahora, despues de eso, estoy investigando, y especulando sobre que podria pasar, e intentando todo lo que pueda conseguir con tal de resolver el problema.

Alguna otra idea o comentario, sera bienvenida.

Gracias.

Tambien, al configurar la forma de replicacion, antes de copiar cualquier registro, se elimina la tabla, y luego se crea nuevamente, para luego insertarles los registros. Por lo que entiendo, que si no existia ningun registro duplicado, no debe existir alguno en la nueva tabla, ya que es una copia lo que realiza.

Tambien, probe con la opcion de eliminar todos los registros antes de copiar los nuevos.

Busque en MSDN, y lei nuevamente el articulo que me comenta sobre este problema, y dice que con el SP3 se resuelve, ncontre que solo aplicaba para el sql standard edition, por lo que cree una pc virtual con W2k3 server, y el sql st edition, y ocurre en la misma forma el error.

Que mas pudo haberseme escapado?

Gracias por tus comentarios.

Si estas REPLICANDO y en tu replicacion existen campos de tipo IDENTITY, hay una forma para crarlos, lee tu ayuda en linea:

Cuando se utiliza la propiedad IDENTITY con CREATE TABLE, Microsoft® SQL Server™ utiliza la opción NOT FOR REPLICATION de CREATE TABLE para suplantar el incremento automático de una columna de identidad. Normalmente, SQL Server asigna a cada nueva fila insertada en una tabla un valor que contiene un incremento mayor que el valor anterior más alto. Sin embargo, si las nuevas filas están duplicadas desde otro origen de datos, los valores de identidad deben permanecer exactamente como eran en el origen de datos.

Hola a todos.

A ver,

Isaias gracias por ayudarme. He tenido este avance en la replicacion.

El problema anterior al parecer tenia que ver con el servicio MSDTC que debia estar corriendo tanto en el distribuidor como en el subscriptor.

Para lograr la comunicacion entre ambos nodos (Subscritor/Publicador) debi de utilizar tanto la cuenta del dominio de windows, como la cuenta administrador de SQL, ambas con derechos administrativos.

No se puede usar la cuenta localhost.

Tambien tube cuidado al seleccionar quien era publicador o subcriptor, ya que me di cuenta que habia problemas al tratar de replicar con publicador que a la vez es subcriptor. (Entiendo no debe existir problema, pero aqui parece ser asi)

En cuanto a los campos identity, lei que en la publicacion transaccional, le cambiaba de identity a identity (not for replication).

EL PROBLEMA 2 DE REPLICACION : despues de este caso.

Sucede que en otra tabla, esta haciendo una conversion a tinyint, pero no se donde la hace, o a que campo se le hace la conversion. Solo se que esta tratando de convertir un valor negativo a un tinyint, por lo que da error.

Comentarios, seran bienvenidos.
Gracias.

Hola a todos.

Para los que estan siguiendo este mensaje, he logrado avanzar un poco mas en cuanto a este tema.

En cuanto a problemas relacionados con el problema 1, la llave de su solucion esta no poner que elimine la tabla y recrearlas, sino que elimine todas los registros, y los inserte de nuevo para el primer snapshot.

Esto es por publicaciones, articulos, y en el detalle del articulo, le ponemos delete all en vez de drop table and recreate it.

Otra cosa que evita errores de Primary Key, es incluir todas las tablas relacionadas a la tabla que se quiere publicar, de por lo menos el primer nivel de la relacion.

Aun tengo problemas con una conversion que esta haciendo la replicacion, y uno truncate a un campo de un primary key, que no tengo idea de por donde lo esta haciendo, ya que en la tabla replicada en la Base de Datos fisica replicada, la longitud de este primary key, es la correcta, es decir, la misma que en la base de datos que de la que se esta publicando.

Aportes, comentarios, seran bienvenidos.

Gracias por leer mi comentario.

DALSOM.

Hola a todos, al fin logre hacer mi replicacion, y resolver todos los problemas que se me presentaron.

Los pasos a seguir para hacer la replicacion sin problemas :

- En caso de no tener un alias, cambiarle el nombre de local a la registracion. (Generalmente toma el nombre de la maquina en que esta instalado sql)

- Hacer un diagrama de las tablas que se incluiran en la replicacion. Esto ayudara a ver cuales tablas deben ser publicadas primero, y cuales tendran un tratamiento especial.

- Definir una cuenta de acceso para que los subcriptores y publicadores puedan acceder a los archivos de Snapshot. (Esto aun no lo tengo muy claro, ya que deberia hacerse todo por la cuenta sa de sql, pero no, tambien hay que utilizar una cuenta del dominio con privilegios administrativos, al igual que la cuenta utilizada en Sql).

- Crear los publicadores y los subscriptores

- Crear la publicacion. En mi caso, le puse que actualizara inmediatamente, y en cola en caso de no poder. Los demas valores, los deje por defecto. Tener en cuenta, quien publicara, y quien sera suscritor.

- Observe que en la lista de publicacion aparezcan tanto la cuenta de sql como la cuenta administrativa de su dominio.

- En la definicion de los articulos a publicar, deben ser publicadas en la primera etapa, las tablas bases o foraneas, las funciones que son utilizadas en las tablas que tienen campos calculados, y las tablas que no tienen campos calculados. Se debe verificar que ninguna de estas tablas tengan algun campo de tipo imagen, y que si tienen algun constraint forzado, ponerle el filtro correspondiente.

- Establezca por defecto para todas las tablas, eliminar todos los registros y copiar todos los datos.
- El collation, que debe cerciorarse al crear la BD en el subscritor, que tenga uno predefinido para toda la BD. Esto le ahorra muchos inconvenientes.
- El propietario en el subscritor, generalmente es el dbo.
- Los indices, y la integridad referencial.

- Para las funciones, que mantenga la funcion existente. Esto asi, porque al eliminar una funcion que es referenciada por un elemento, no hace la replicacion correctamente.

SUBCRIPCIONES
- Al crear las subcripciones, logre hacerlas trabajar al crearlas para que se sincronizen en el suscritor.

- Estableci un collation para toda la nueva base de datos que se crea en el servidor en donde esta esa data replicada.

Etapa 2.

- En la segunda etapa, pare el agente y el logreader.

- Agrege los elementos restantes que tenian campos calculados.
- Reinicie el Snapshot, luego el logreader, y por ultimo el agente.

*- Siguiendo estas normas, logre corregir todos los errores anteriores descritos.

Si me ha faltado algo por incluir en esta pequeña guia, por favor, hagan el aporte, ya que soy algo novato en esta parte. Pero espero que esto le sirva a muchos otros.

Saludos,
DALSOM
REP. DOM.