Skip to main content

    Filter by idea status

    Filter by product

    859 Ideas

    rory.smith
    TimeXtender Xpert
    rory.smithTimeXtender Xpert

    Improve 'stacked' data sourcesSUBMITTED

    Many customers have ‘stacked’ sources: many instances of the same source (BC / Dynamics, etc.) that in the TX Classic release can be easily handled with Additional Data Sources. Here you define the data selection in the ‘master’ source and have the same data extracted from the underlying clones.In TDI you would currently need to have separate sources for each and use the, very restrictive, mapping set feature to auto-map tables with identical (field, data type) structure to the same Prepare table.The possibility of cloning data sources and using connection strings / json settings, makes the creation of many of the same sources easier. There are still two issues remaining however:Each additional source needs the data selection set and maintained separately If one of many ‘stacked’ sources updates by adding or changing metadata, this will break mapping setsThe first issue could be solved by allowing to clone Metadata Manager settings from one ‘master’ source to secondary sources with the same structure. It should be possible to do this before the initial metadata sync task is automatically triggered. In this situation I would expect that the Metadata Manager shows you:What is successfully found in the target from the source mapping What was not found in the target from the source (maybe due to a schema name difference, etc.) What exists in the target additionally to what is in the sourceIf in future one of the sources updates to add a new field, it should be possible to clone this across easily once the other sources also get this field. I expect you would mark one source as the ‘master’ for its set, and others as receiving mapping changes. The second problem occurs when there are deviations between data sources that cause Mapping Sets not to work. If one of the sources has an additional field in a table with respect to the others, it will not work. In my opinion a mapping set should be an intersection of common fields, not an exact match. This way new fields added won't break Mapping Sets already existing and the feature becomes more widely useful. If a source in a Mapping Set no longer has a field, just drop the mapping and warn the user.

    hgrContributor

    Renaming QVD and Parquet files from semantic layer across environmentsSUBMITTED

    Feature Request: Improved Environment Handling and File Naming in Semantic Endpoints in TimeXtender (Classic)In our current setup using Qlik Sense endpoints to generate QVD and/or Parquet files for Semantic Endpoints in TimeXtender (Classic), we have two environments (DEV and PROD), each designated to write files to different folders. Our directory structure looks like this: QVDs│├── DEV│ └── <QVD Files>│├── PROD └── <QVD Files>Under each environment's folder (DEV and PROD), the QVD files should have the same name to facilitate switching between folders in Qlik Sense without requiring changes to QVD names in the script.ProblemCurrently, we use the Postfix Option (_DEV and _PROD) for each environment. This setup forces Qlik Sense scripts to connect using:LIB CONNECT TO 'MDW';instead of:LIB CONNECT TO 'MDW_DEV';andLIB CONNECT TO 'MDW_PROD';This ensures that data is loaded from the respective database environments (DEV and PROD).An unintended consequence of this setup is that every QVD file is saved with the environment postfix:<QVD_Folder>\<QVD Name>_DEV.qvd<QVD_Folder>\<QVD Name>_PROD.qvdTo make the scripts work, we must manually find and replace _DEV.qvd with .qvd and _PROD.qvd with .qvd, so the files are named equally across both environments.Feature Request1. Environment-Specific Connections: We request the addition of an option to change only the connection name in the Qlik app script without altering the file name postfix of the QVDs. This would allow:LIB CONNECT TO 'MDW_DEV';while keeping the QVD filenames consistent.2. Parquet File Generation: We also request an option to enable automatic Parquet file generation. Currently, we manually change:_DEV.qvd];to:.parquet] (parquet);This feature would simplify our workflow by directly supporting Parquet file generation.BenefitsImplementing these features would:Eliminate manual file renaming processes Streamline the deployment of Qlik Sense across different environments Facilitate efficient data management with automatic Parquet file supportWe believe these features will greatly enhance usability and maintainability in TimeXtender.Thank you for considering our request.