Skip to main content
Version: v2.6

Release 2.6.12

Issues fixed

Deploy no longer fails with 'Access is denied'
When deploying an engine from a server accessed through Remote Desktop, the sign-in window could fail with an Access is denied error — and once it appeared, it kept coming back until a browser data folder was deleted manually.

Deployment now recovers from this automatically. No action is required, and the manual workaround is no longer needed. Should a recovery occur, the only thing you may notice is being asked to sign in again.

Delivery feedback no longer stops on an item that has been removed
When feedback from the target system referred to an item that no longer exists in the migration database, the load stopped on that line. Nothing further was loaded, neither from that file nor from the other files in the folder, and because the files were left in place a new run failed in the same way.

The Target Feedback extension has a new setting, Fail fast on not found. It is on by default and keeps the load failing immediately in that situation. Turn it off to have the load record each such item in the job log and carry on with the rest. The run is still reported as failed, so the skipped items are not overlooked.

Feedback that only clears the messages of an item that no longer exists is now ignored, and is not treated as an error.

Faster loading of data files
Loading data files became much slower after upgrading from 2.5 to 2.6. Large files could take around three times as long as before.

This release fixes the slowdown, and file loads run at their usual speed again. The fix is included in the updated software and needs no separate action.

Faster export queries in the migration database
The 2.6.0 upgrade removed an index from the item table in the migration databases. Without it, some export queries read the whole item table, and the database no longer enforced that each item has exactly one row.

This release restores the index. It is created by the database migration script for 2.6.12, which must be run in all migration databases. Should creating the index fail with a duplicate key error, the migration database contains duplicate item rows and needs repair; contact support before rerunning the script.