The platform here is actually Windows XP SP2
The behaviour of DAOS with a new replica appears inconsistent. I have repeated this exercise many times now and have found the following variations. In these examples, both source and target servers were clustered and were running DAOS.
New stub did not have DAOS property selected
New stub did have DAOS property enabled (this was the more common situation)
Pulling from target server turned off DAOS property - full replica received. In this situation, the DAOS property was turned on for the stub before the replication started but it was off at the end of the replication.
Pushing from source server created abbreviated db with DAOS repository populated. However, after the replication the DAOS property of DB on source server was found to have been turned off at some point.
Pushing from source server created full replica copy
Running a compact -C for the first time on a full replica copy (with DAOS property enabled) did not move attachments to the DAOS repository. The DAOS property was enabled before the compact but was found to be off after it had completed.
Running a compact -C for the first time on a full replica copy (with DAOS property enabled) did move attachments to the DAOS repository
Running a compact -C for the second time on a full replica copy (with DAOS property enabled) did move attachments to the DAOS repository and left DAOS property enabled - this always happened.
QUESTION - what should be happening in a new replica situation? What is the recommended sequence of events for an administrator to follow? Would that be different depending on whether the source server has DAOS running or not?
REQUEST - the desired behaviour is that for a source db which has the DAOS property enabled. any new replica created onto another DAOS server is created as a DAOS db and that a separate compact -C to do that is not required. Obviously, the DAOS property on the database must never be changed by the replication process (or the compact process for that matter).