We are currently looking for a way in which we can update the source database independently of the Replication database. 

We have successfully been able to architect our solution in a way that would prevent data loss without having to rely on bulk loading.  Essentially we turn of replication processing at the time of the schema change and let the queue records load up with any changes made during the schema change.  Then when the replication side is updated we flip the switch to enable processing again. 

The issue with this is that when a new table is added, as soon as we add the new table entry to the ReplTableXref table the processing becomes unstable.  The process will continue to run, but if it is restarted for any reason,  The process will not run until a mapping .p exists on the replication side for that table. 

However,  hypothetically if the system would ignore ReplTableXref records where queue processing is set to false, you can let any changes to a new table build up on the source side and just ignore them until your ready with an updated version of the mapping files on the destination side.  In this case the replication as process as a whole would not be disrupted and the other tables could go on replicating without issue.

Then lets say you update the replication schema and put the correct mapping files in place.  You turn the ReplTableXref record procqrec to true and restart the process.  Now the correct files are in place with the proper schema definition and the system can now process outstanding changes to the new table with any changes made to it in the meantime.  

This could also potentially help in scenarios where a schema change is made on a table when the runtime version of progress is running on the replication side (which is currently what we are using).  The current issue here is that if a new field is added to an existing relicated table and the mapping files have been compiled against the old schema, any time the mapping file is called on the replication side you would get a CRC error due to a mismatch in schema between your source and destination databases. 

In this case if you preempt the change by turning off replication on that table, which in turn stops the call of any mapping file from happening,  you will avoid the CRC issue and also let the changes build up in the queue for when the latest update has been applied to replicated database.