This INFO post is
a serious oxymoron.... an "empty full" replica sounds as ironic as any
other oxymoron, after all. The principle is as follows:
1) Take your database (pre-replicated state) and remove all the data from it (just keep the structure fully intact). Keep the data in a separate file so you can append it later.
2) Make the db replicable, and create a replica from it. That replica will be a full replica that is empty of data.
3) Fill your DM with data and then use it to create other replicas.
4) Whenever you synchronize that "empty full" (EF) replica, do a one-way synch from the EF replica to some other full or partial replica. This will make sure it stays empty of data, but it will keep the schema up to date.
5) Make sure to keep the EF replica unmanaged by any synchronizer (because you cannot make one-way scheduled synchs, and because other uses of EF replicas make managing the replica contraindicated).
SO, what can you use EF replicas for?
1) Their original inspiration came from a comment Alden Streeter made in the
microsoft.public.access.replication newsgroup, related to the fact that there was no way to make two partials synchronize with each other on a client site... thus there was no "replica as backup" functionality available with partial replicas. Basically, by copying an EF replica to a local machine (a simple file copy is safe here since there is no data in it and thus no risk of creating errors; you can also create a new replica off the EF replica and just MoveReplica it down to the local machine. Even over 28.8 an empty replica will copy pretty quickly). You can then do full two-way synchs between the partial and EF replica. By always synching through the partial replica with your hub--NEVER the full replica--you guarantee that your formerly EF replica is now a FULL replica that is a de facto partial (DFP) replica since the only data it ever will have is the data that is contained in the partial anyway. You now have a backup! And an easy way to create a new partial if you need it! As long as you never do a two-way synch with the hub, or some other full replica with all data, this useful DFP replica can save you in a lot of ways.
2) A common problem for people who do not create replica farms on their servers is that for some reason the Synchronizer will be marked as invalid and then all synchs will fail, until either a direct synch is done or some other drastic measures are taken. And the knowledge that a replica farm will solve the problem in the future is a bitter pill to take when you see that you have to find some way to make the remote replicas learn that the Synchronizer does indeed have suitable partners set up. Well, you can now use EF replicas as an easy way to update them! Simply add the extra full replicas to be managed by the Synchronizer, make sure all of those replicas are synched to each other, then do a ONE WAY SYNCH (important!) from the EF replica to one of those replicas. NOW you can MoveReplica the EF replica to the remote machine (should be pretty fast as there is no data in there!), and once it is on the local machine, do a one-way synch from the EF replica to the replica on the remote machine; then MoveReplica it back to the server. This will update the remote replica with all of the info on who the synchronizer has managing, etc., and allow the synchs to work again!
Do not try to create an FE replica by taking a full replica with data and deleting the data out of it! If you do this, you will cause all data to be deleted when you next synchronize with the other replicas! So this work MUST be done before you replicate the database. The only other way to do this is to create an RFE (see the glossary below).
FE Replica: A "Full Empty" replica, which is a full replica that is not managed and has no (or almost no) data in it. It is safe to filecopy it since it has not done any data operations and thus cannot cause data errors or conflicts. It should only do one-way synchs to full replicas.
RFE Replica: A "Retroactive Full Empty Replica" If you can, grab a copy of the August 1997 issue of the Access/Office/VB Advisor (or grab a reprint from http://www.advisor.com) and look at the article Peter Miller and Mary Chipman wrote entitled "Effective OLTP/OLAP Balancing Thru Creative Replication." This shows you how to delete the Tombstone records, which allows you to create a full replica, delete all the data, and then delete all the tombstones so none of the data in other replicas will get lost -- the perfect way to create an RFE! Once this is done, you will have all the features of an FE replica.
DFP Replica: A "De Facto Partial" replica, which is a full replica that is not managed, which has only ever synched with a partial replica. Therefore, although it has all the abilities of a full replica (like creating new replicas, doing synchronizations, etc.), it only has the same data as the partial replica with which is has synchronized. This makes it a "de facto" partial in terms of the data it holds... and is ideal for creating backups of the partial replica, and, if needed, replacing a corrupted partial replica.
So, use these new administrative types of replicas today!