Build better products with our product team
Since the business unit settings dialog is rather poor on options I would like suggest some additions. When using the BU as an ODX it would be good to have it automatically organized. By having the options to always sort tables alphabetically by default and group tables into folders by schema, that would give better visibility in large projects in my opinion.
A source identifying field is needed in a setup where the ODX is in simple mode and there is a need to merge data from multiple tables into a single staging table. If there is no source identifying column in the tables we are forced to remove simple mode from these source tables to be able to add a custom field with a fixed value to distinguish between the data in the staging layer.
Today we have the option of an automatic prefix on the data source that concatenates the data source name with the schema name. Having the option to only prefix with the source schema name would be a nice option when building a clean ODX where you have a schema for each data source. That would allow tables with the same name in different schemas without also having the data source name in the prefix.
It would be very useful if you could add a default data row for a dimension table in a similar way you add custom data but without getting a custom data table and where you can set DW_Id = -1, which is common. The input ui could be in the same dialog as the custom data input or a separate dialog. The ways to do it now are either: 1. Creating a post-deploy script for each dimension table where you do SET IDENTITY INSERT ON and then an insert statement with all the values. 2. Adding a new custom field to use as a surrogate-key column, persisting dw_id from staging and inserting default values with custom data option. Numer one is very un-DWA and boring to maintain and number two is somewhat going around things to get the desired resaults and having a custom table for each dimension table just to hold the default value is maybe unnecessary. Attached image is a quick mockup :) Best regards,Andri default-values.png
Having the option to do a full load on incremental tables when adding objects to the execution list would be handy.
Add function to see the usage for Project Variables. When changing a Project Variable, it can be handy to see the impact for this change. Just like the 'Show usage' option in Snippets and custom scripts.
When changing a table, depending tables are marked red and need to be deployed again. When changing a Semantic model, it is not marked red. Add same logic as staging/data warehouse tables on semantic model when it needs to be deployed again.
The analyst should always be able to see the timestamp of when the data is extracted from the source system. This is especially important in validation processes, but also as metadata information during analysis. Using Business Unit one could make use of the DW_TimeStamp field. This does not exist in ODX. Technically, one may copy the SQLLite backlog file and extract ODX execution information into DWH. However this would require considerable effort as one would have to set up a task (e.g. batch script) to regularly copy the SQLLite backlog file, make another TX connection to it and merge the data in the DWH. Adding a DW_TimeStamp on ODX tables would be ideal. Other solutions could be to make the ODX execution details more accessible, e.g. as a table in the ODX. (Ticket #21213)
An option to manually "fix" the data lineage for custom table inserts as is in place for custom views would be very appreciated.
Our client would really like to be able to see the differences between two saved versions of a project, similar to a differential deployment report. There have been a number of other requests for functionality like this: The ability to compare two projects Compare project versions in multiple environments Multiple environment transfer + version totes (request for version saves to show differences listed in the comments) This feature would go a long way towards providing transparency in the development process, which would in turn make multiple developer development easier to do. I think that level of transparency would also help non-BI experts gain trust in the tool. Best regards, Doug Wynkoop
being able to see the version history on object level, maybe right click => advanced. To be able to see who made what changes would be very helpful in projects with team development.
Add a new subject parameter for mail notifications that includes the environment name.
So we have a lot of views in our MDW which serve as an interface between MDW and Semantic Layer.If we update a lot of dim_tables, we have to synchronize the views one by one which is not really an "automated" job. Please provide an option to synchronize all views with "one" click.
When you transferred the project to another environment. You need to deploy it, after the deploy the tables are truncated. When you want to execute the newly deployed tables, you need to remember all tables that are newly deployed and execute them one by one. It would be great to have an option to deploy and execute the tables in the new environment (from the multiple environment transfer window).
It would be useful, to be able to copy/paste a measure in the semantic layer. Since there is no option to hide an intermediate measure, we often duplicate parts of the measure calculations, but it is quite time-consuming to re-map all the parameters.
Hi Guys, I would be nice to give all members of the db_owner role access to all data in secured views. This way report designers can use the view even though they are members of db_owner. You could have a flag 'Give duo full access' for example. You could simply add OR IS_ROLEMEMBER('db_owver') = 1 at the end of the view definition. Regards, Lars
Hi Guys, It would be extremely helpful if incremental tables are highlighted during deployment when a full load is triggered. As it is today we need to expand every incremental table to see if the Full Load checkbox is checked or not. This will minimise the risk of full loading an incremental table by mistake. Basically just highlight the table when TX decides to check the Full Load checkbox. Regards, Lars
Hi Guys, It would be extremely helpful if we could somehow see the exact reason for the error when "Continue with no/existing Data" is enabled on an additional data source. Is it caused by a Timeout, a non-existing field on an additional data source, truncation of text field etc. Currently we can only see the table was not loaded. Not why. Regards, Lars
Consider the following setup: PRODUCT-table in ODX PRODUCT-table in DSA PRODUCT-table in MDW When highlighting one of the tables it would be nice to see somewhere central (top bar or bottom bar) what table is actually highlighted when scrolling through fields. It's easy to loose overview when scrolling through a long list of fields or tables and it would therefore be nice to see somewhere which table actually has the focus atm. This would also reduce the risk of errors in case one did an unwanted click somewhere by accident.
For execution packages there should be a WarningStep with possibility to get Mail, In many cases when you are having issues with connections to source data, you need to use ex continue with existing data. In those cases the success message contains info about the warning. But we should not be relying on external systems to filter and monitor success messages for Warnings, to get notification about these events. So I suggest a WarningStep. A step when the Execution package has been able to be completed, but it contains warnings.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.