Release 2.5.29

Issues fixed

Target maps that give a Num value to a Float parameter now build
When a method parameter of type Float, for instance on a bag method, was given a Num value such as a Num constant or a Num bag property, the target map validated without errors but failed to build when deployed from Visual Studio: the generated code did not compile.

A Num value given to a Float parameter is now converted to Float, and the map builds and runs as expected.

Translation booleans stored as 1 or 0 keep their value when a row is edited
In a translation Valueset uploaded from a spreadsheet, a boolean stored as 1 or 0 used to show as an unchecked box when the row was edited, and saving the row, even after changing only another field, stored False. Such a value now shows as checked or unchecked, and the stored value changes only when the box is changed.

Note that the list of rows still shows a stored 1 or 0 as it is.

Maps that pass a value of a compatible type now build
Previously, a map could validate without errors and still fail to build when deployed from Visual Studio, when a value was used where a different but compatible type was expected:

• in a source map, a Guid value given to a Char parameter of a rule or bag method;
• in a source map, a Num field of the business object being exported given to a Float parameter;
• in a source or target map, a Valueset lookup whose default is a system constant of another type than the returned column: a Num constant for a Float or Char column, or a Guid constant for a Char column.

These values are now converted to the expected type, and the map builds and runs as expected.

Loading or optimizing views no longer fails when several indexes on one table are rebuilt
Loading or optimizing views rebuilds the indexes that the views' queries need. When several of those indexes were on the same table, they were rebuilt at once, and the job could fail with a deadlock error. The indexes of one table are now rebuilt one after another, and indexes on different tables are still rebuilt in parallel.

Truncate and Load stops before emptying a source table that has no files
When a source table loaded from files had no file to load, a Truncate and Load job for it, for instance one started from Automation, emptied the table and completed with 0 rows. The job now fails with the message that there are no files to load, and the table keeps its rows. The Portal already refused to start such a load; tables that are loaded directly are unchanged.

The Events page no longer fails when an event was renamed
When the project held occurrences of an event under both its old and its new name, Migration > State > Events showed "An error occurred" and no events. The Event filter now lists such an event once, under every name it has carried, and the page shows the events. Filtering by that event finds occurrences under either name.

Validating a project in Studio no longer checks every item reference with the Repository
Previously, validating a project in Studio asked the Repository, for every item reference in a map, whether the referenced item had been deleted. On a large map this made validation slow, more so with the Repository on the network. Validation now reads these states from the list Studio loads once when validation starts, and the results are the same. A delete that another user checks in while a validation is running shows up at the next validation; Publish still checks the Repository.