FAQ Unicode UTF-8

On this page you find answers to the most common questions concerning the Automic Automation Unicode UTF-8 implementation.

Q: Is it mandatory to use the Automic UTF-8 migration Action Pack to migrate the database from v21 to v24?

A: The Action Pack only migrates the data from non UTF-8 to UTF-8. The upgrade from v21 to v24 has to be performed separately.

The migration is only necessary if your source database is a non-UTF-8 database. It is not mandatory to use the Action Pack. If you want to use a vendor or third party tools, you can also use them for the data migration. It is important that the resulting AE database has the same schema and data as the original one, but configured for and encoded in the desired UTF-8 format.

Q: Which options are available to migrate the data from non-UTF-8 to UTF-8?

A: There are 3 options available:

  1. The Automic UTF-8 migration Action Pack, see

  2. Vendor or third party tools

  3. DB Unload / DBLoad (for objects only)

For more information, see Migrating AE Databases to UTF-8.

Q: Is it possible to load a v21 Transport Case to import objects into a v24 system?

A: Yes. The DBLoad Utility used for importing a v21 Transport Case into v24 has a new command line parameter (-Z Encoding) that can be set to state the source/legacy encoding used to unload the data so that the it gets converted accordingly.

If the -Y command line parameter is not stated, the legacy encoding set in the XML_ENCODING parameter of the UC_SYSTEM_SETTINGS variable is used.

Using the Transport Case to transfer data between systems is only supported when using the same database (vendor). Otherwise, issues may arise, for example, case sensitiveness of keys in VARAs.

For more information, see:

Q: Is it possible to upgrade directly from v12.3 to v24 or do I have to upgrade to v21 first?

A: Yes. You will have to convert your v12.3 database to UTF-8 by either using our UTF-8 migration Action Pack, a vendor or third party tool before you upgrade the system to v24.

Q: Does the UTF-8 DB migration Action Pack allow switching the database vendor (for example from Oracle to Postgres)?

A: No. The Action Pack only works between databases of the same type (for example, from Oracle to Oracle).

Q: Is the UTF-8 migration Action Pack compatible with v12.3?

A: Yes, it can be imported to v12.3, too.

Q: Is it possible to run the UTF-8 migration Action Pack from a third Automic Automation instance or the target Automic Automation instance?

A: No. Please run the migration Action Pack from the source Automic Automation instance.

Q: Do I have to turn on the Windows Beta feature for UTF-8 before I run the migration Action Pack?

A: No. The Beta feature for UTF-8 is only required on servers running v24 software that is accessing a v24 Automic Automation database running on MS SQL. This feature is not required to run the migration Action Pack.

Q: Is it possible to have the source and the destination database on the same host?

A: Yes. However, on Windows you will not be able to run v21 and v24 in parallel because, for v24, you must have the Beta feature for UTF-8 enabled.

Note: Be aware that running both the v21 and v24 databases on the same host requires additional resources; therefore, it makes sense to install the v24 database on a separate host.

Q: I would like to install the v24 Automation Engine on the same server as v21. Does enabling the Windows Beta feature for UTF-8 have an impact on v21?

A: We recommend enabling the Windows Beta feature only after your v21 instance has been shut down and before you run the upgrade to v24. It is needed for enabling Windows to process UTF-8 correctly, for example in case that you use UTF-8 specific characters (i.e. Hebrew) in an agent job.

Q: The UTF-8 migration Action Pack requires a database link to be defined. Where do I have to create it?

A: The database link has to be created on the destination database to point at the source database. For Oracle, the migration Action Pack is able to create that link automatically.

Q: Does the target database require to have the Automic Automation v24 schema created before I run the migration Action Pack?

A: No, the database has to be empty. The schema including all the tables, indexes, and so on is created by the migration Action Pack.

Q: I created an empty database created by the DBLoad Utility. Can I use this empty database as the target database?

A: No, the target database has to be empty. The schema including all the tables, indexes, and so on is created by the migration Action Pack.

Q: The documentation indicates that there will be a temporary table created in the source database. Do I have to reserve extra space for it?

A: No, this table is not used for migrating data but to store internal information that is used by the Action Pack to allow the REFRESH step to be run multiple times and to correctly create the statements for the FINAL step. It only contains a few rows of data.

Q: Does the migration Action Pack support rollback/fallback?

A: No, this is a temporary table used to store metadata only to control the migration flow itself, such as saving step states (initial, refresh, final). It contains just a few rows and is irrelevant in terms of consuming additional databas space.

Q: Is it possible to restart the Automation Engine during running the INITIAL or REFRESH mode?

A: Yes, as long as the database is available the migration continues running.

Q: The Action Pack does not support PostgreSQL. Does it mean that PostgreSQL databases do not require a migration?

A: Yes. Your PostgreSQL database is already on UTF-8, therefore no migration is required.

Q: Do I need temporary disk space when I migrate an AE database and all its data is copied?

A: When using the Migration Action Pack, the data is copied on the fly from the source to the destination AE database: therefore, no extra disk space is needed. The expected disk space for the destination AE database (physical files behind the database) is not significantly larger than the one of the source database as the UTF-8 character representation should not have any big impact (some single-byte characters will be extended to double-byte, such as German umlauts).

Q: What is the expected size of my destination AE database after I finalized the migration and all data is copied?

A: There is no simple answer to this question. We observed that in case of copying a streamlined and well-reorganized source AE database, the destination database might be slightly larger in size. In case of a very fragmented source database, the destination database is sometimes significantly smaller in size (assuming all data was copied successfully).

Q: How can I check whether all data was copied or not, as comparing the sizes of the source and destination database does not seem to be a good indicator?

A: The key indicator is to compare the data that got copied from the source to the destination database.

Q: Is the read_committed_snapshot setting for MS SQL AE databases mandatory also in UTF-8 context?

A: Yes, as described in the user documentation this setting is still mandatory, see Preparing the AE Database - MS SQL.

See also: