Release 2.5.24

Other improvements

Browse the Source Object tree without checking out the object

When an object is not checked out, you can now scroll the Source Object tree to see where a value's source comes from.

Before, the tree was disabled while the object was checked in, so you could not scroll it. On a large extraction map the source could be off-screen and out of reach.

The tree is now read-only in this state: you can scroll and see the highlighted source, but you cannot change it. Check the object out to make changes.

Check Query now matches the full validation of a Source View

When you test a Source View with Check Query, Studio now runs the same checks as the full validation.

Before, Check Query only confirmed that the query was valid. It did not check the query result against the Exposed Fields, so a view could pass Check Query and then fail during full validation.

Now, when the query is valid, Check Query also checks the query result against the Exposed Fields. Check Query and the full validation give the same result.

If the query has an error, Check Query reports only that error, so you can fix the query first and check the fields afterwards.

The separate Match button has been removed, because Check Query now does the field check for you.

Issues fixed

Clearer error when importing a Valueset with blank values in required columns
Importing a translation Valueset could fail with an unexpected error when a required column contained a blank value.

The import now reports which row and column is missing a value, so you can correct the file and upload it again.

Connection string passwords are masked in the job log
When data was loaded through a direct table load, the connection string was written to the job log. If that connection string included a password, the password was visible in the log.

Connection string passwords are now masked in the job log. The rest of the connection string, such as the server and database name, is still shown to help with troubleshooting.

Export errors are no longer hidden by a failed key insert
During export, the Director stores the key of each dependency between items. When this key insert failed in certain ways inside the item transaction, the database procedure hid the original error. The export then stopped with the unrelated SQL error 3930, "The current transaction cannot be committed", and the real cause was lost.

The procedure now reports the original error with its true source. Recoverable situations are still handled as before: a key inserted by another process at the same moment is re-read, and deadlocks are retried when the transaction is healthy.

Note that this fix makes the real error visible so it can be addressed. If the underlying error was caused by server resources, such as a full transaction log, that condition still needs to be resolved on the server.

Cancelling a queued job now always prevents it from starting
When more jobs were submitted than the maximum number of concurrent jobs, the job next in line for a free slot could ignore a cancellation request. The job was shown as Cancelled but still started, synchronized and processed items.

The job scheduler now tracks every job through the whole hand-over from the pending queue to execution. A cancelled job can no longer start, regardless of when the cancellation arrives.

Note that cancelling a job during its synchronize step takes effect when synchronization completes. The job then stops as Cancelled and no items are processed.