• Precisely - at our shop we've got one publisher and 2 subscribers using transactional replication with queued updating.

    We regularly use the subscribers as hot standby machines to allow maintenance on the publisher.

    Updates flow reliably back to the publisher.

    To do this we increment our identities in 10s and have a different seed on each server so that the identities don't clash.  Then we set the "not for replication" option on the identity columns so that the subscribers don't replace identies written ont he publish with ones of their own.

    Easy peasy.  The only caveat is that if you reinitialise the publications and snapshot the tables back to the subscribers then yo need to reset the seeds on the subscriber as the seed from the publisher is carried thorugh with the snapshot.

    Since the updates are queued on the subscriber the publisher can be offline and updates are queued up.  As soon as the publisher is back on line these get pulled through and get all the servers back in sync.

    I'm not entirely clear what is new here in 2005 - can you elaborate?