ImportSetUtil generates sys_update_xml records - Known Error

ImportSetUtil generates sys_update_xml records Description When performing XML imports using the ImportSetUtil Script Include, the sys_update_xml table is being updated, even if no structural changes are made. The following output log was traced in a London instance:

Script completed in scope global: script Script execution history and recovery available here Operation Table Row Count insert sys_update_version 2 insert sys_update_xml 2 update sys_db_object 1 insert sys_user 1 insert cmn_notif_device 1 Upgrading table: sys_user Replication is not enabled on table: sys_user, not queueing replication table change special db event sys_domain_path field already exists in sys_user Background message, type:info, message: Primary email device created for Marty Grinstead.Example Slow business rule 'Create primary email device' on sys_user:Marty Grinstead.Example, time was: 0:00:00.101

This produced two rows in the sys_update_xml table, with the following values: TYPE...............Table Name...............Name Dictionary.......User..............sys_dictionary_sys_user_null Table...............User..............sys_db_object_d8b34b6313e16300027879d96144b08a

Steps to Reproduce

1. Execute the following script from Scripts - Background:

var xml = " "; xml += " "; xml += " marty.grinstead.example "; xml += " m.g@example.com "; xml += " Marty "; xml += " Grinstead.Example "; xml += " "; xml += " "; var xmlDoc = new XMLDocument(xml); var importSetUtil = new ImportSetUtil(); importSetUtil.loadFromXML("/import/sys_user[1]/*", xmlDoc, "sys_user");

2. Check the sys_update_xml table and notice the two new rows generated.

3. If testing multiple times, make sure the value for the user_name is unique.

Workaround After carefully considering the severity and frequency of the issue, and the cost and risk of attempting a fix, it has been decided to not address this issue in any current or near future releases. We do not make this decision lightly, and we apologize for any inconvenience.

Within the ImportSetUtil script include there is logic which checks for existing column names in a table and removes them from the schema changes hashmap. There is no check to determine whether or not the schema changes hashmap is empty or not before executing the update call on GlideTableCreator.

The workaround is to check the size of the hashmap prior to executing the update call which ends up creating the extra rows, as follows:

Navigate to the System Definition > Script Includes > ImportSetUtil page.

Look for the following lines of code below and place the 3 lines of code within an if statement as shown below.

BEFORE WORKAROUND: // create or update the table schema var tc = new GlideTableCreator(tableName, tableName); tc.setColumnAttributes(attrs); tc.update();

AFTER WORKAROUND: // create or update the table schema if (attrs.size() > 0) { var tc = new GlideTableCreator(tableName, tableName); tc.setColumnAttributes(attrs); tc.update(); }

Save the changes.

NOTE : Updating an OOB script include will result in the inability to automatically update the specific script include during further instance upgrades.