Release 2.6.9
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
Fixed: migration export could fail for items without persisted XML
The migration export pipeline could fail with a database error when an item had no source or export XML to persist — for example when the XML was intentionally not stored, or when it could not be parsed. Export now skips storing XML in that case instead of sending an empty value to the database, so the run completes and the affected item is recorded with its parse error. This brings the 2.5 and 2.6 release lines in line with the equivalent 2.4.32 fix for the same class of failure.
Translation Valuesets with null in numeric columns now upload, download and load correctly in the Portal
Translation Valuesets containing null values in numeric columns did not round-trip correctly. After uploading a Valueset with [null] in a numeric column, downloading it returned an empty cell instead of [null], and loading the Valueset into Staging could fail with a conversion error ("the given value '' of type String … cannot be converted to type decimal").
Empty text in non-text columns is now consistently stored and treated as null, so null numeric values upload, download and load into Staging as expected. Rows previously corrupted by this issue are recovered automatically on load.
Fixed: unload from an ItemSet failed with a missing MetaData.xml error
Unloading from an ItemSet could fail with an error that the generated file _Generated\TargetSystem\MetaData.xml was not found, even though the file was present. The unload now locates the target engine metadata correctly, matching the other unload types. Other unload types were not affected.
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 synchronization no longer fails on very large entities (ticket: 4646)
Synchronizing an entity with a very large number of items (around one million or more) could fail with the database error "Error severity levels greater than 18 can only be specified by members of the sysadmin role, using the WITH LOG option".
This message hid the real cause. The synchronization processed all items in a single database transaction. For very large entities this transaction could exhaust the resources of the database server, and the resulting severe error could not be passed on correctly.
The synchronization now processes items in batches. Each batch is committed on its own, which keeps the resource usage on the database server low and stable, regardless of the number of items.
In addition, if an error does occur during synchronization, the original error from the database server is now reported correctly.