Skip to main content
To homepage To homepage

    Filter by idea status

    Filter by product

    859 Ideas

    bas.hopstaken
    TimeXtender Xpert
    bas.hopstakenTimeXtender Xpert

    Pre execution conditionsSUBMITTED

    Add an option to set conditions before an executon task starts. For example. We want a condition that the task 'Execute DWH'  starts when all execution packages (multiple packages) from the DSA are successfully executed. 

    1
    bas.hopstaken
    TimeXtender Xpert
    Forum|Forum|8 years ago
    W
    Contributor
    WimContributor

    Automation: when using Additonal Adapters / Connections, include DW_SourceCode in primary keySUBMITTED

    As title says, if you consolidate multiple sources, you need DW_SourceCode in the PK should the PK field of a table be the same in 2 databases. We see this in scenario's where companies want to consolidate multiple ERPs / sources but the ERP uses integers as PKs for companies / locations etc... This gives PK conflicts, which is solved by adding DW_SourceCode to the constraints. Navision is less impacted if the DW_Account is unique between two databases, but we have had a conflict there already so we add DW_SourceCode to the PK. So it would be great if the automation feature would take this into account and add the DW_SourceCode in the PK when Additional Sources are used.

    2
    W
    Contributor
    Forum|Forum|8 years ago
    bas.hopstaken
    TimeXtender Xpert
    bas.hopstakenTimeXtender Xpert

    Make video about new featuresSUBMITTED

    It would be great to make a video each release of a new version of TX DWA which explains all new features in the release. 

    2
    bas.hopstaken
    TimeXtender Xpert
    Forum|Forum|8 years ago
    M
    Visitor
    mvannordenVisitor

    Table Settings TemplatesSUBMITTED

    Hi, It would be nice to be able to create your own table settings template. If you want to have many tables that need to keep history and load incrementally, it would save time if you could select the template with the settings you defined. Also, if many tables that rely on such a template need to get a different setting, you would have a central location to change the setting.

    0
    M
    Visitor
    Forum|Forum|8 years ago
    bas.hopstaken
    TimeXtender Xpert
    bas.hopstakenTimeXtender Xpert

    Publish to Qlik Sense stream from TimeXtenderSUBMITTED

    Add an option to publish a Qlik Model from TimeXtender to a specific stream in Qlik Sense.  

    0
    bas.hopstaken
    TimeXtender Xpert
    Forum|Forum|8 years ago
    S
    Participant
    steven.koppenolParticipant

    Improved usability for table icon hintsSUBMITTED

    Many have suggested additional information to be immediately visible in the table icons. While the desire is understandable, it is also poor UX to try to put them all in a tiny icon. Instead of one merged icon before the table name showing a limited number of indicators, I would propose to show a series of icons or tags after the table name. In the preferences, the user can then choose which indicators to show. For example, I would want to see the following flag: * delete handling (no/soft/yes) * type 2 history fields (none/any) Reason is that this is part of the external contract for a table. Everybody using a table must be aware of whether they need to handle effective dates and tombstone flags.

    1
    W
    Forum|Forum|8 years ago
    bas.hopstaken
    TimeXtender Xpert
    bas.hopstakenTimeXtender Xpert

    'Unqualify All' Button/Option Qlik ModelSUBMITTED

    Add an option to unqualify all fields in Qlik Data Model.

    0
    bas.hopstaken
    TimeXtender Xpert
    Forum|Forum|8 years ago
    andri
    Contributor
    andriContributor

    Easy and controlled way to sunset a replaced source..SUBMITTED

    ..with the ability to run data from it again on demand. Consider the scenario where an ERP system is upgraded/replaced with a new one. Historical transaction data will not be migrated to the new system. Most but not all dimension data (customers, products, divisions etc.) are created in the new system. Data from the old ERP db will still be accessible. In TX we add a new source, new staging tables, and new cleansing rules. We map the new source to existing dimensions and facts. The old source is still mapped as well. Dimensions have history enabled and we do a surrogate key lookup in the facts. Source system is not a part of the PK. Many of the facts are incrementally loaded. We stop extracting data from the old system by guarding the source. The staging tables stores data from the last load (not securely though, it could easily be truncated in a future deployment if source settings change or a new TX release triggers a re-deployment?). We also should empty the old staging tables that are feeding a dimension since we need the new source to take over updating the dimension data. We don't want to remove the old source mappings of the dimensions in case we might need to run them again in the future (not all dimension data was created in the new system). Ability to disable/guard the data mapping of the old source might help? There are different ways to deal with this but there could be a better fully thought-out way to handle this scenario in TX (it's an imminent problem for a maturing data warehouse). Since all development for old and new is contained in the same project it requires a different approach than traditional ETL development where there is more separation and manual control. A white paper on a subject like this would be nice to have. How to use TX to handle different known data warehouse development dilemmas.

    3
    andri
    Contributor
    Forum|Forum|8 years ago
    J
    Starter
    jake.entrekinStarter

    Ability to convert a staging table to a Custom table?SUBMITTED

    TX version 17.1.5.64 SQL 2016 Standard.   We have a situation where a large table in AX (INVENTTRANSORIGIN) does not have a MODIFIEDDATETIME field available to execute incremental loads off of.  Our customer is experiencing performance degradation issues with the load due to the large volume of data it's having to reload daily. This table is also feeding a dimension, so we have history enabled.  We were going to attempt to execute target based incremental data loads, but you cannot apply that setting to a history table. One option would be to replace this table with a query table and have that do the incremental load logic from the source, but this is going to require a TON of rework as the table's surrogate key is referenced in dozens of other tables. Is there a way to either modify the staging table to be a custom table so that it's 'disconnected' from the source?  This would allow me to create a separate incremental query table and have that load our existing staging table via a custom table insert. Or is there a way to convert an existing staging table to a query table without having to start from scratch?  Thanks!  

    2
    J
    Starter
    Forum|Forum|8 years ago

    Filter by product

    • All products
    • TimeXtender Data Integration
    • TimeXtender Data Integration Portal
    • TimeXtender Data Enrichment
    • TimeXtender Orchestration & Data Quality
    • TimeXtender Classic
    • Data source providers
    • Exmon
    Terms and ConditionsAccessibility statement