Build better products with our product team
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.
We have the following request: the ability to disable a future execution of a scheduled package for a specific date/time.Our servers undergo periodic maintenance on Sundays, and these dates are known for the entire year. During these times, we do not want any disruptions in the packages and currently have to disable and re-enable them manually.
When cloning an Ingest instance in the TX Portal, it is currently not possible to include all mapped data sources. You have to add them manually after the cloning process. If you have a lot of data sources mapped, that will cost you quite some time. Cloning an Ingest instance should have the option to include cloning the mapped data sources.
I think it would be nice to able to link DEV and PROD instances together. Example if you have multiple Prepare instances in both environments that you could somehow say that Azure DW DEV is linked to Azure DW PROD to make sure that you don’t migrate it over some other irrelevant PROD instance or at least by default the linked instance would be selected and you should force it to migrate to some other instance if that’s what you want to do.I would also like more overview on the process and be able to press retry if the migration failed. For example if someone had the destination instance open and therefore the migration failed. Then you have to create the log and everything again - would be nice to be able to close the instance in the TX UI and then press retry or something like that.
With the new release Data Areas are implicitly implemented as schemas in the backing database. As you can also apply schema behaviours and rules per table, this can become a bit messy (or make users not use these functionaliities). It also makes it unclear what a best practice for implementation would look like.It is understandable to have the features that exist in 20.10.x available to be able to migrate existing projects into the new release. I think it would be better to relegate this functionality to deprecated (i.e. hidden for new implementations). That would make the setup something like:Instance (implicitly a database) Data Area (implicitly a schema) Tables Views .. This allows users to split an instance into separate areas, for instance to have separate staging per source. I would then add an option to push “technical tables” to separate schemas, i.e. _R _I _M _PK etc.Needing to go to table settings and individually assign schemas takes too long to be really useful and should no longer be required in the new release outside of dealing with migrated implementations.Additionally, it would be good to be able to perform data movements between instances as this allows you to create a setup where you have separate instances for staging and a central instance for merging and MDW storage. This allows you to have multiple smaller Hyperscale instances and not be limited by log I/O thereby greatly increasing the throughput and size applicability.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.