Ha habido mucha confusión respecto a esto, así que lo siguiente espero que ayude a explicar a todos exactamente, porque el hacer esto es algo malo.
Déjame empezar por decir que la REPLICACION es muuy buena. Te deja hacer cosas que simplemente no hay otra manera de hacerlas. Esto NO se puso para quemar la replicación, si no para quemar a las personas que tratan de usarla en una manera para la cual no fue diseñada.... y expone muchas de las razones de porque lo que estas personas hacen es un peligro para sus aplicaciones y la información en ellas.
************************************
EL PROPOSITO DE LA REPLICACION: Tener dos o más copias de una base de datos Jet que siempre se consideren a una sincronización de ser idénticas. Múltiples personas pueden hacer cambios a múltiples bases de datos pero al final todos alcanzarán "convergencia" y será lo mismo. El soporte es para usaurios conectados y ocasionalmente conectados.. más no PARA usuarios desconectados. La replicación de Microsoft Jet no soporta el escenario cuando no tienes una verdadera conexión de internet, directa ó indirecta. Punto.
************************************
FONDO DE MOVER/COPIAR: Siempre que Microsoft Jet, abre una réplica (para sincronización, ó si tu aplicación la abre, como sea) determinará si la réplica ha sido movida. Hace esto mediante la comparación del camino y la computadora. Si determina que no están en la misma locación, asume que has copiado una réplica y básicamente le dará a esta réplica un nuevo IDRéplica (hay concecuencias muy malas para dos réplicas con el mismo IDRéplica). Así pues, si tienes un conjunto de réplicas con cuatro réplicas, y mueves la locación de una réplica y luego la abres.....Jet pensará que tienes CINCO réplicas en el conjunto de réplica.
Esto se aplicará en todos los siguientes escenarios:
1) Moviendo una réplica a un diskette y luego usando el diskette para trabajar en la réplica en tu casa ó en otra locación
2) Mover/copiar directamente en DOS o Explorer
3) Moviendo una réplica via un disco zip para trabajar en ella via dos máquinas/caminos diferentes... al menos de que la computadora/camino sean idénticos, Jet considerará esto como una "copia" aún si lo dejas en el disco zip y sincronizas desde ahí.
4) Mandando por correo electrónico una réplica a tora persona
5) Cualquier otra manera de copiar que se te pueda ocurrir, bajándolo de una página de internet, un servidor de archivos, etc.
Esto no se aplicará en los siguientes escenarios:
1) Usando los métodos ya integrados para mover una réplica, ya sea via el comando de menú del Manejador de Replicación (Replication Manager) ó el método del Sincronizador de TSI de Mover Réplica (TSI Synchronizer MoveReplica).
2) El Reconciliador de portafolio (briefcase reconciler)
Ahora, este comportamiento ocasiona que haya un error, uno muy enfadoso y tres problemas por diseño que son MUY MALOS y que ocasionan corrupción y/ó pérdida de información.
************************************
ERROR #1: Hay un error solitario en el manejo de estas cosas de "cambiando el Id de la réplica" en Jet....no limpia la información mientras el Sincronizador maneja la réplica dada. Así es que si usas el Sincronizador para Replicación de Internet/Indirecta de Jet y copias una réplica manejada a otra parte, Jet creará una nueva réplica mas sin embargo seguirá pensando que el viejo Sincronizador la sigue manejando. Y si no, entonces puede haber problemas cuando trates de hacer sincronizaciones y cosas por el estilo. Si era una réplica que estaba sin manejar, entonces no verás ningún tipo de problema. Ha sido confirmado por personas internas a Microsoft, que esto es un problema pero ya que el escenario no tiene soporte, no se consideró lo suficientemente importante para arriesgar una versión de servicio de arreglo. La manera de trabajar alrededor del problema es no manejarla ó administrarla, etc. ó crear una nueva réplica de la forma legal y luego tendrás una sin manejar.
************************************
ENFADO #1: Como vayas moviendo.copiando estas réplicas, la lista de réplicas se incrementará como pase el tiempo y verás más y más réplicas aparecer en la lista de réplicas (por ejemplo) en el menú de Herramientas de Access|Replicación|Sincronizar (Access Tools|Replication|Synchronize) y en el Manejador de Replicación. Si eres una de esas personas que copia de una computadora a otra varias veces, entonces todas las réplicas falsas serán del mismo camino..... así es que puedes terminar con miles de réplicas "c:\foo\bar.mdb" en la lista. Remover estos elementos no es cosa trivial ( escencialmente Jet solo marca como removido y propaga esta información a las demás réplicas si te sincronizas a ella y puede encontrar el camino más no el archivo...así es que si puede ver c:\foo\ pero no hay bar.mdb ahí, lo ha removido. Si haces esto 1000 veces, removerás mil entradas. Existen otra maneras imperfectas de "remover" réplicas falsas que no son tan efectivas como esta.
************************************
PROBLEMA POR DISEÑO #1: Microsoft Jet 3.5x tiene un límite de 64,000 sincronizadores que son "conocidos" a una réplica. Obviamente este no es un problema en la mayoría de las aplicaciones, pero date cuenta de que si no manejas una réplica con un sincronizador, entonces Jet crea un sincronizador "virtual" que puedes usar con un sincronizador real (muy bueno para sincronizaciones en internet y parecidas). Esto significa que a medida de que sigas copiando, eventualmente tendrás 64,000 réplicas inválidas, y listo. Has echado a perder tu conjunto de réplicas y no podrás arreglarlo fácilmente y sin mucho trabajo.
************************************
PROBLEMA POR DISEÑO #2: Conflictos de datos, los cuales ocurren cuando dos personas actualizan el mismo renglón, y reportado solo en la réplica perdida para Jet 3.5. Así que si tienes una réplica que perdió un conflicto pero has movido la réplica (entre el tiempo en que metiste la información y el tiempo en que sincronizaste donde se reportará el conflicto), recuerda que es ahora una NUEVA réplica, y así has perdido la información que estaría contenida en la tabla de conflictos. Esta PERDIDA DE DATOS es obviamente muy seria.
************************************
PROBLEMA POR DISEÑO#3: Errores de datos, los cuales ocurren cuando dos personas afectan la integridad de la base de datos (la manera más fácil es cuando dos personas ponen la misma llave primaria para un nuevo registro y luego sincronizan), es muy malo. Siempre que sincronizas, Jet asume que corregiste los problemas y "tratará" nuevamente la sincronización para ver si el problema fue resuelto. Si encuentra que el problema sigue ahí, para la sincronización (de esta manera no hay trabajo subsecuente y no se transfieren más registros). Ya que la información reportada para errores de datos es muy cerrada respecto a de que réplica proceden, etc, es MUCHO más difícil rastrear la causa del error de datos cuando la réplica en cuestión ya no está... solo hay pocas personas que yo conozco que han sido capaces de resolver tales situaciones sin ir al extremo de la solución de desreplicar/volver a replicar. Nota que las sincronizaciones NO son completadas enteramente cuando existen errores de datos...así es que no todas las réplicas obtendrán toda la información, y de esta manera te encuentras en un estado inconsistente. No tienes control sobre el orden de las operaciones cuando esto ocurre.
************************************
CODA: Finalmente, el escenario total (ya que no hay soporte para él) nunca se le dió la prueba extensa de estress que se les da a otros escenarios. Nos burlamos de las pruebas de los productos de Microsoft, pero el hecho es de que las pruebas de estress son cruciales y que nunca hayan sido probadas significa que adicionalmente a los puntos discutidos previamente (los cuales he ido encontrando, identificando y corrigiendo ya por varios años) pueden haber otros temas que aún no se han encontrado. Irónicamente, las personas que más critican MS por sus errores en sus productos, descartarán esta queja.
Para el registro, antes de que se haya distribuído la replicación Jet, para Jet 3.0, NADA de los problemas antes mensionados eran conocidos ó comprendidos. NO OBSTANTE siempre he recomendado a las personas que nunca deben de mover ó copiar una réplica con información en ella; nunca. La razón es que *Yo* he prestado atención a la recomendación anterior de no hacer cosas para las que no haya soporte para ellas. Como tal, nunca he tenido una aplicación que haya yo creado que le halla tocado NINGUN tipo de problemas como estos. Sin embargo, he estado involucrado personalmente ayudando para recuperar más de 70 aplicaciones difrerentes en los últimos años, que han tenido serios problemas debido exclusivamente a este tema. El costo total estimado del cliente es ALTO, ya que las personas tercamente insisten en hacer esto, ignorando todas las precauciones.
************************************
Así es que, por que no "ser como yo" :-) y nada más no trates de hacer cosas que no haya soporte para ellas ó que no hayan sido probadas, especialmente cuando hasta este punto haya sido probado que causan problemas tan extensos.
