Replicación !!!

Aquí hay una serie de datos importantes a la hora de elegir el tipo de
replicación:
- Van a estar conectados continuamente todos los equipos ? supongo que no en
tu caso, ya que los comerciales se irán desplazando, y la idea es que cuando
vuelvan a la central sincronicen datos.
- Van a actualizar datos estando desconectados ? supondo que los comerciales
irán grabando pedidos y otra información.

Confirmame si las suposiciones son correctas. Si he supuesto bien, en este
caso deberás implementar una duplicación de mezcla (merge replication). Y en
ese caso también es muy importante que en tu diseño intenten minimizar los
conflictos, te pongo un ejemplo para aclararte: si todos utilizan la misma
serie de pedidos tienes más posibilidades de conflictos, ya que en dos
tablets se podría dar de alta el pedido 127. Ante esto puedes optar por
asignar rangos de numeración diferentes, o utilizar una serie, por ejemplo
harán los pedidos ABC/0001 ABC/9999 y en otro los ABD/0001 ..., y así
sucesivamente. Lo mismo con los clientes, si los dan de alta, etc

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"Javier Carrascal" escribió en el mensaje
news:

Ahora lo entendí ...

En mi caso, necesito disponer de los datos (replicados) en dos bases de
datos distintas. La base de datos publicadora, estará en el servidor, al
que
ataca una aplicación Web, y las bases de datos suscriptoras, estarán en
unos
tablet que utilizaran los comerciales.

Salu2

"Salvador Ramos" escribió en el
mensaje news:

Hola:

Porque tu hablas de replicar datos en general sin indicarnos tu caso

exacto.

Por ejemplo si quieres tener un servidor preparado para ponerlo en marcha

en

caso de fallo del servidor activo, sería interesante implementar log
shipping, también si quieres tener un servidor con los datos replicados y
utilizarlo para consultas, en fin, el múltiples casos puede ser una
alternativa de replicación de datos. Ahora si estás pensando, por ejemplo

en

dos servidores, que en ambos se actualicen datos y se mantenga la
información sincronizada, pues ahí no lo tiene. Log shipping es una forma
más de replicar datos, otra cosa es que se adapte a tus necesidades
concretas (que no comentas en tu pregunta).

Espero haberte aclarado :-)

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"Javier Carrascal" escribió en el mensaje
news:
> Gracias a ambos por responder ...
>
> No había caido, "duplicación" :S, me ha servido de mucha ayuda ...
> De todas formas, lo que no entiendo, es el porque de pensar en

implementar

> un LOG SHIPPING
>
> Salu2
>
> "Isaías" escribió en el mensaje
> news:0c5201c5042e$6b40c220$
>> Aparte de lo que comenta Salvador, si tiene SQL 2000
>> Enterprise, puede pensar en implementar un LOG SHIPPING
>> (Transavase de Datos)
>
>

esta liga te podria ayudar con algo de interesante informacion, espero te sirva

http://msdn.microsoft.com/library/d...s_2f8z.asp

"Salvador Ramos" escribió:

Aquí hay una serie de datos importantes a la hora de elegir el tipo de
replicación:
- Van a estar conectados continuamente todos los equipos ? supongo que no en
tu caso, ya que los comerciales se irán desplazando, y la idea es que cuando
vuelvan a la central sincronicen datos.
- Van a actualizar datos estando desconectados ? supondo que los comerciales
irán grabando pedidos y otra información.

Confirmame si las suposiciones son correctas. Si he supuesto bien, en este
caso deberás implementar una duplicación de mezcla (merge replication). Y en
ese caso también es muy importante que en tu diseño intenten minimizar los
conflictos, te pongo un ejemplo para aclararte: si todos utilizan la misma
serie de pedidos tienes más posibilidades de conflictos, ya que en dos
tablets se podría dar de alta el pedido 127. Ante esto puedes optar por
asignar rangos de numeración diferentes, o utilizar una serie, por ejemplo
harán los pedidos ABC/0001 ABC/9999 y en otro los ABD/0001 ..., y así
sucesivamente. Lo mismo con los clientes, si los dan de alta, etc

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"Javier Carrascal" escribió en el mensaje
news:
> Ahora lo entendí ...
>
> En mi caso, necesito disponer de los datos (replicados) en dos bases de
> datos distintas. La base de datos publicadora, estará en el servidor, al
> que
> ataca una aplicación Web, y las bases de datos suscriptoras, estarán en
> unos
> tablet que utilizaran los comerciales.
>
> Salu2
>
> "Salvador Ramos" escribió en el
> mensaje news:
>> Hola:
>>
>> Porque tu hablas de replicar datos en general sin indicarnos tu caso
> exacto.
>> Por ejemplo si quieres tener un servidor preparado para ponerlo en marcha
> en
>> caso de fallo del servidor activo, sería interesante implementar log
>> shipping, también si quieres tener un servidor con los datos replicados y
>> utilizarlo para consultas, en fin, el múltiples casos puede ser una
>> alternativa de replicación de datos. Ahora si estás pensando, por ejemplo
> en
>> dos servidores, que en ambos se actualicen datos y se mantenga la
>> información sincronizada, pues ahí no lo tiene. Log shipping es una forma
>> más de replicar datos, otra cosa es que se adapte a tus necesidades
>> concretas (que no comentas en tu pregunta).
>>
>> Espero haberte aclarado :-)
>>
>> Un saludo
>> Salvador Ramos
>> Murcia - España
>> [Microsoft MVP SQL Server]
>> www.helpdna.net (información sobre SQL server, Windows DNA y .NET)
>>
>> "Javier Carrascal" escribió en el mensaje
>> news:
>> > Gracias a ambos por responder ...
>> >
>> > No había caido, "duplicación" :S, me ha servido de mucha ayuda ...
>> > De todas formas, lo que no entiendo, es el porque de pensar en
> implementar
>> > un LOG SHIPPING
>> >
>> > Salu2
>> >
>> > "Isaías" escribió en el mensaje
>> > news:0c5201c5042e$6b40c220$
>> >> Aparte de lo que comenta Salvador, si tiene SQL 2000
>> >> Enterprise, puede pensar en implementar un LOG SHIPPING
>> >> (Transavase de Datos)
>> >
>> >
>>
>>
>
>