> Guillermo,
> there are several choices, depending on your setup:
> If you are expecting conflicts then the (out of the box) choice is between
> queued updating and merge replication. Queued updating won't work if you
are
> replicating BLOBs but it is generally much faster than merge, especially
as
> you only have one subscriber.
> If the data is completely partitioned, you could use bidirectional
> transactional replication (not out of the box though).
> If there is continual connectivity (unlikely as you are using MSDE as the
> subscriber) then immediate updating subscribers could be relevant.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
>

> Guillermo,
> if you go down the transactional route, you'll still have schema changes
for
> updating subscribers. You're quite right that bidirectional transactional
> replication isn't an option as you have MSDE and hence can't publish from
> it. So, for merge or transactional you'll have another column added. If
you
> want a solution that doesn't alter the schema at all, then for your
> requirements you could consider Redgate DataCompare which just uses
Primary
> Keys as identifiers. BTW, what is the problem with the schema being
altered
> to add the extra column?
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
>
>