Build better products with our product team
If you are lucky, Excel files to be loaded into a data platform contain named ranges or defined tables that allow you to only load data required. I.e. a certain range of cells could be given a name or defined as a table, avoiding all sorts of setting complexity to parse the Excel data.In the TimeXtender Excel connection you can currently restrict data loading to ‘defined tables only’, but this refers to table definitions you need to input yourself. If you are loading statistics (like the recently disappeared US Census data), those typically have table definitions which avoid all the textual context meant for human consumption. The current process is to open the Excel (requiring an M365/Office install or license), find the definition of the named range or table, copy-paste that as a table definition in the portal and load that.I would like to have an option where the TimeXtender connector recognizes the named ranges and tables contained within the Excel and presents those. I.e. ‘Only use defined tables from the Excel file’, ‘Only use defined tables from the Data Source settings’ as toggle options. This way I never need to open the Excel imanually f it is properly defined and future changes to the ranges won't require manual intervention like they would now.
Hello,The option to enable/disable job schedules would be great.For example when maintenance on the vm’s is planned.Another situation would be when we are planning an upgrade and I want to make sure no jobs are running (instead of killing the running jobs as multiple jobs are running during the day). If you can disable the schedules in the evening you do not have to delete them, write down somewhere what the schedule was and recreate them when the upgrade is finished.I hope it can be made available.Greetings, Roy
Currently, it appears in the preview when executing an execution package that an excluded table would actually be executed. Only after the execution you can see that the excluded tables were skipped. I suggest excluded tables are unmarked in the preview to avoid confusion.
With the older 20.10.44.64 desktop version with repo and warehouse databases on Azure SQL Databases. I'd like to provide access to a user to view the TimeXtender projects, but limit them to not be able to edit them. Is there a good way to do that?Can I just use a read-only credential for the warehouse database and the read-only ODX credentials?Can I install the TimeXtender application on multiple workstations using the same license key but not enabling the scheduler service and not installing the odx service on the workstations?
If I create a Conditional Lookup field, it will by default use the Max operator to enforce only one result from the lookup. If I change the operator to Top without a Sort specified (give me the first record whatever it is, formally non-deterministic) , I get the same code as I would with the None operator.While it seems the result of the None operator code enforces 1 result for the lookup (which is mandated by the SET statement, see: https://learn.microsoft.com/en-us/sql/t-sql/queries/update-transact-sql?view=sql-server-ver16#best-practices). I wonder if you could prove that the undetermined result from the INNER JOIN is the same record as would have been returned by a TOP(1). I suspect that it may not always be the same record.If I specify a Sort, I see that the code implements a Top 1 explicitly. What I would like is that a Top operator without a sort gives a warning on apply / Deploy that offers the user a choice:None operator (because this code will mostly be faster, but not always) explicit Top without Sort. This option will almost always be slower and may or may not return the same result as an INNER JOIN would, but will be explicitly what the user asked for. The option to specify a Sort: this may actually be what the user needed.This choice could be influenced by the operators on other lookups in the table, as bundling them together is faster than running them serially.See some code examples below. I have a list of breweries, which guarantees mutliple breweries for some US states. And I have a list of states with population per age. I am looking up an age from the state table to the brewery table based on the state name being equal. There are at least 87 records for each state ( age 0 - 85 plus 999 for people over 85 years of age). Max operator: Top without sort / None operator: Top with sort:
There are a number of ways data can be moved to tables, a number of these are shown as mappings. A number are not: Table Insert, Custom Table Insert, Add Related Records do not show in mappings and cannot be easily overseen.As these functionalities all have mappings internally, they should also show up in the mappings folder. An example of where this is useful is if you have a Fact table that consists of many subfacts that are mapped from an underlying area. You may want to split off the subfacts as separate tables and then do a table insert inside the same layer. During this operation you would want to use features like Show Uneven Mappings to check that your mappings are correct. However, you do not see the Table Insert and therefore need to take screenshots.I propose that Table Insert, Custom Table Insert (parameterised), and Add Related Records integrate with mappings. This would also mean being able to use Smart Synchronize and View Uneven Mappings and seeing the Table Insert etc. under the field.
When we use the icon inside a package to see the “Execution History” it would be more usefull to see the history filtered.
It would be very usefull to know the origin version number in a instance migrated from DEV to PROD.
Hi,To clarify which environment the open data areas belong to, I suggest that the environment name is shown together with the data area name in each tab. The image shows where the environment name would be added. This would decrease the risk of changes being made in the wrong environment.
When configuring an instance, we are able to use Microsoft Entra Service Principal to authenticate to the underlying Azure SQL Server.However, when using dynamic values in a data source, Microsoft Entra Service Principal authentication does not seem to be supported.This is a problem for us, because we have a SQL Server that we want to limit authentication to Entra ID only.Adding Microsoft Entra Service Principal authentication to dynamic values would be benificial.
During the TimeXtender partner event Xtend24, it was announced that version V20.10 will no longer be a Long-Term Support version. It will be rebranded as TimeXtender Classic and used for SQL-only infrastructure setups. They also announced that new features will be developed for TimeXtender Classic.There are some features in TimeXtender Data Integration that would add significant value to TimeXtender Classic as well. Please consider making the following features available for TimeXtender Classic if possible:DAX Snippets DAX Calculation Groups Xpilot Integration Deploy to Power BI Premium/XMLA endpoint Data Profiling PowerShell package support The newly developed TimeXtender connectors for: Exact Online, Business Central, Salesforce (and any new connector that will be available in the future) Context-sensitive help (links to articles on the support site)
Dear, when creating a new data source connection, my colleague cloned it from an existing instance and the adjusted the ingest instance mapping. Whereas mistakenly there is an unwanted character in the short name as below.After hitting the clone button it appears not possible to change the short name anymore. Thus the name in the storage account container is also incorrect. Could you advice how we can change this short name?The setups (such of pk and incremental settings) of the data source are completed, and the DW_SourceCode is also used as a calculated column and loaded to the following layers so it is not impossible to create the data source from scratch but would cost a lot time.. That is why we want to see if it’s still possible to be edited.Thank you in advance
When setting up row-level security (RLS) for tabular semantic layers, so-called security tables are created in the data warehouse. For instance, we’re having a semantic model called ‘UFO201az [...]’ and row-level security enabled on field [PersoneelsgebiedKey].In the MDW this table is created:: RLS is dynamic, so all members and values are read from a table, which has its origin in a source system and is being refreshed on a daily base.While all tables in the data warehouse are daily refreshed, these security tables only refresh when the semantic layer itself is executed from within TImeXtender. For reasons we use external triggers which directly refresh the tabular models (XMLA endpoints actually, but with TX 20.10.39, hence this ‘odd’ workaround :) ). This way of refreshing the endpoints does NOT include the security tables used for RLS, which means that new authorizations won’t appear in the model.Is there a trick/hack/exploit/statement/stored procedure/etc to refresh these security tables outside from TimeXtender? It would save us some pointless executions of full models, just to keep the RLS in sync.
It is currently possible to define a default value for a column as a transformation. Due to the (rather strange) choice of using an actual transformation for this, it is impossible to apply this to Simple Mode tables.It is quite common to want a backup value for a field in case a mapping does not fill it. In staging tables you will commonly need to add a transformation with an IsEmpty condition, in MDW tables you need to turn off Simple Mode and add a transformation with a default column value. The latter adds a raw table with associated I/O.A better solution would be to use a named default constraint (see: https://learn.microsoft.com/en-us/sql/relational-databases/tables/specify-default-values-for-columns?view=sql-server-ver16) that uses DDL to ensure a field gets a default value if it is not specified in an insert. Obviously this means dropping the constraint to change data types, but that is minimal overhead compared to the advantage of not needing explicit transformations.Default column constraints can also be applied in bulk operations (see: https://learn.microsoft.com/en-us/sql/relational-databases/import-export/keep-nulls-or-use-default-values-during-bulk-import-sql-server?view=sql-server-ver16) meaning that they can also apply to Custom Data. This is an improvement to the current status quo there: Default column values make the model more explicit and allow a user to see this information from the database structure instead of needing to dive into code. A default value should be a property of a field, not a transformation. The fact that SQL Server deviates from the ANSI standard does not block the implementation here. Additionally, this allows more use of Simple Mode which should speed up performance.
At the moment custom data to snowflake is not supported.We use this to easily add the dimension record -1But you also can not use pre- and post steps to insert data via a stored procedure.So hopefully it can be made possible to use custom data in combination with Snowflake.
At this point it is not possible to add/use pre and post steps on tables when the prepare instance is a Snowflake one. As we have quite some stored procedures executed in scripts in pre and post steps this is a significate one for us in the deployment to snowflake.
The limit of 15 characters for the name on data sources and database objects needs to be increased.
Can we get a SQL Export option in the new TimeXtender Deliver Instances. If we could Select “SQL Server” in the portal like we can select “CSV”. Used this extensively in V20 and have clients in the new SAAS application that are requesting this capability.As it is no longer a feature I currently have to construct this export outside of TimeXtender which creates problems in synchronizing TX load processes and the subsequent export.Or I can create a dummy “Transform” instance that I point to the destination database and use it just to export the tables. But this comes with extra licensing costs just to be able to export to SQL.
Hi, At the moment scheduling ODX task is done using UTC time but Package execution schedule to run on local timeAs there is clearly dependency between the two, it makes it extra difficult to synchronize the task execution and the package execution. My suggestion is have the ODX task schedule also run on server's local time. Or alternatively enforce UTC time on package execution. Ideally would be to integrate the ODX and Package executions into a single scheduler container.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.