6.3.7 Repository Synchronization Tips & Techniques

Following are some general tips when using repository synchronization:

• Do not leave lots of developers in a work group if they are not actively working on the development. Consider removing inactive developers from the group, and then when they need to get the updates, get a complete refresh by means of an import. After the import, you can add them back into the work group if required.

• When there is a large volume of changes, an import is an efficient update option to consider. For example, if a developer has been away on vacation for two weeks, you should remove them from the work group and use an import when they return to work.

• When developers are working, leave the Host Monitor running. Changes will be propagated as they happen.

• Developers should consider checking in changes more frequently, in logical units of work, instead of performing a large volume of changes all at once.

• If the Visual LANSA Host Monitor is stopped before a synchronization is complete, data may be left in transit. If the Visual LANSA Host Monitor is restarted before a LANSA for i database reorganization, then it will continue from where it stopped and data will not be lost. A LANSA for i database reorganization removes data that's in transit. So, to ensure there is no data in transit, make sure that synchronization is complete before stopping the Visual LANSA Host Monitor.

• When deleting a field on a slave system, an integrity check is run only on that system. Slave systems cannot be relied upon to have the whole repository and therefore this check is not a true integrity check. When the delete is propagated to the Master, an independent integrity check is performed. If the field is found to be used in a file, then the field will not be deleted on the master.

There are at least two ways you can successfully use the slave system to delete an object from both master and slave:

1.  If the field to be deleted is used in a file and if that file is no longer required, on the slave system, delete the file definition, then delete the field. Note: Make sure you select the option Delete from host repository for each delete, to propagate the delete to the Master.

2.  If the file is still required, on the slave system, delete the field from the file definition and check the updated definition into the Master. Then delete the field, making sure you select Delete from host repository to propagate the delete to the Master.