Build better products with our product team
The ability to load an execution package with parameters, would be a way to limit the number of business unit. For instance I use the NAV adapter, but need to build several BU in order to separate differenct companies pr country. Having the functionality to execute a package with a "where clause", in this case the dw_account field, would eliminate the overhead.
We are using the Navision adapter extensively with several accounts in Navision/BC. It seems that the Nav adapter uses the Nav Account Name to reference the objects in the Nav database. We are now looking to update and change the Account Name of some of these companies in Nav. We see that it creates issues with incremental tables, history tables and snapshot tables when a company changes name in Nav/BC. So a change of the company name in BC will update the value in the Company table and then rename all the table objects to reflect this change. This would add duplicate records in both incremental, history and snapshot tables. In BC they now have a unique company id field called "Id". So even if the company name changes, this id will be unchanged. A better setup of this adapter would be to use this id as the DW_Account on all objects in TX. Then it doesn't matter if the company name changes in Nav/BC. TX would use this id internally on all objects, but reference the table object with the value in the Company.Name field.
Hi, We are using the Google Analytics connector to pull large amounts of data from the Google Analytics API. We also use the Data Source feature with Additional Connections. This lets us pull data from several Google Analytic Views with a single implemented Data Source and Query Tables. We pull data from seven Additional Connections and it would be really good to be able to enable and disable some of these from time to time, in order to pull data from only one of the Connections. These data pulls uses GA data limits and runs for quite some time on large amounts of data.
Your manual states that the import and export feature is useful "if you want to reuse parts of a project in another project." But this feature only allows for import and export of the whole projects, and not parts to be included in a new project. Selection templates partly solves this for Data Sources, but it does not solve the issue of moving objects from Stage/DSA into another project.
It should be possible to universally set compression settings to ON. So that all newly created objects are automatically compressed. Today we have to manually set this on all new objects.
I'm working with a company that regularly receives large comma separated text files from external parties ... large as in 2-300 columns. It would be nice with a couple of features for specifying column data types: 1. Based on the first X rows (where X is user specified), Discovery Hub could make an initial data type suggestion, just like when we import data from a file in SSMS. 2. Multi-selection of fields (the usual Ctrl and Shift functionality) to update the data type for all fields in one go, also like importing text file data in SSMS.
When you swap a table over to incremental loading manually, it would be really helpful if you got a quick popup dialog box with the following options: 1) Add source table DW_TimeStamp as an incremental field 2) Pick my own incremental field (taken to the incremental field selection pane) 3) Skip picking an incremental field for now With 1) as the default selection. Business unit tables, of course, would only get options 2 and 3. I think this would be a really nice little quality of life improvement that manually setting up incremental loading much faster and easier, and avoid the common problem of an error on deployment when no incremental field has been selected.
The new visual layout of Discovery Hub is very handy! One quality of life improvement that might help speed routine use of the tool would be to list the execution packages under the Execution Package node in the Solution Explorer, and allow them to be executed or dragged to the execution queue from there. That would save having to open the execution package tab unless you wanted to actually make changes to the packages.
We need scripting in the tabular model in the same fashion as it is possible in the OLAP model meaning that we can add scripts at different levels as well as pre and post scripts on the model it self.
We are in the position where we are working major changes against a given project. The changes are expected to take some time to complete. Meanwhile, smaller MOB projects force us to make changes. We would need a solid methodology for deploying ONLY the portion of the project necessary to deploy the MOB projects. We are a SOX company and separation of duties are a large issue here and we do NOT want to manually make the changes directly in production. We also do not want to deploy untested objects into our production environment by deploying the entire project. This is a serious issue for us, and we need a solution if we are going to continue to make use of TimeXtender as part of our BI solution. Thanks!
The new multi-pane layout of Discovery Hub is great, but it has a bit of a problem in that the windows aren't context sensitive in some cases - what happens in one window happens in all windows. An example of this is creating relations between tables. Doing this with the same database open in two panes makes this process much easier and faster! Except that creating a relation cause the UI to snap to the relations node of the table where the relation has been created. It does this for all panes and windows that contain this table, even though you'd want it to only happen in the "destination" pane and nowhere else. Honestly, as a more advanced user I find the "snapping" functionality to be frustrating. But if it has to happen, making it happen in all windows and panes makes the new layout much less useful for tasks like creating relations.. Another example is opening tables in new windows. If you have multiple panes open, and open tables in a new window, if you close any of the panes, all of the open windows close. It would be very helpful to close only the windows that were opened from the pane that's being closed.
We currently have the ability to create role based security on individual fields within Semantic Model Tables, but there isn't the ability to restrict access to an entire table in the model.
On table insert it would be nice to be able to fill out the system field 'DW_SourceCode' just as any other field on the table you are filling with data. Regards Jens Jørn
Some features have been added recently to automatically add the joins necessary for handling SCD Type 2 lookups from a History Table. I'd like to suggest another enhancement which would save a ton of time and manual clicking when we're adding Surrogate Keys to fact tables. Dragging and dropping DW_ID from a history table to a fact table is easy. But the process of adding the Fixed transformation for a -1 "Unknown Bucket" requires a lot of clicks, is error prone, and is something I despise doing. I'd like to suggest the following enhancement to the new dialog that appears when dragging a field from a history enabled table. Note that this option should only be available if dragging DW_ID. A simple checkbox to add the surrogate key "unknown bucket" transform fixed transformation and also add the Is Empty condition: There have been several times where developers have clicked on the wrong field for the condition, or forget to add the condition, so this would be a great help. Also, try adding the transform and the condition 25 times for 10 fact tables. Your mousing hand will quickly agree with my suggestion. I promise!
I had a request come from a customer today which seems like a good idea. They have to maintain strict SOX controls, so knowing what version was deployed, by who, and when are important pieces of information their auditors need to know.Currently, when a project is transferred between environments, there isn't any notation in the project version notes.It would be very useful to simply add the information displayed after a successful transfer to the target environment's new version created by the transfer: So, in this case version 69 was created in PROD. It would be very nice if the information circled above was entered into version 69's notes. Otherwise my SOX compliant customer will need to maintain manual logs of transfers.
Enabling the "Show System Control Fields" in project settings will not make system control fields visible for existing table in the project. The tooltip does indicate that it " will automatically be added to new tables...". However, I think it would be useful to add the option to show system control fields retroactively, so you don't have to enable them for each existing table object manually. Thanks
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.