Limitations of Object Resync

Generating a resync script is a complex process that has a number of limitations. In all cases it is recommended that you view the resync script, to ensure that it is doing something sensible, before you run it.

Some of the limitations are as follows. This relates to case of comparing tables:

• if you have renamed a table, the compare will not detect this. The resync will drop the old table and create another one with the new name. This may result in the loss of data.

  To avoid possible problems such as this, you can de-select the option DROP objects if not present in other schema.

• similarly, AQT cannot tell that you have renamed a column. It will drop the column / add a new one. Again, this can result in the loss of data.
• there are a number of differences that AQT cannot resync. In these cases AQT will give a warning message to this effect.
• for DB2 for LUW, when columns are dropped or have their data type changed, the table can be placed into reorg-pending state. You can only do further operations on the table once a reorg has been done. AQT will not do this for you - this is something that will have to be done manually. You may need to do this multiple-times during the course of the resync script.
• if you have a large resync script that is creating a lot of objects, the creation of foreign keys, views and/or triggers may fail as the dependent objects have not been created yet. The solution is for these objects to be created at the end of the script (after the changes to the tables have been done).

  AQT will currently not do this; this is something we will consider as a future enhancement.