Timextender Data Integration 26.3

Timextender Data Integration 26.3 is here, and it's a big one: full support for Fabric Warehouse and much improved support for Fabric Lakehouse as Prepare instance storage. In addition to that, we have a bunch of other improvements and fixes. The one you’ll notice first might the the smallest, though - we’ve aligned the versioning with the other Timextender products so this release is simply ‘26.3’ and not a four-digit number. 

A big thank you to everyone in our Early Access program who've surfaced a lot of the issues we've fixed in this release.

We hope you’ll like the new release - dive into all the news below!

New & Improved

Full Support for Fabric Warehouse as Prepare Instance Storage (Public Preview)

You can now use Microsoft Fabric Warehouse as Prepare instance storage, with feature support generally on par with SQL Server today. Warehouse is T-SQL based end to end, so it fits naturally into how Timextender already models, deploys, and scripts your Prepare layer. If you've been wanting to run Prepare on a T-SQL-based Fabric engine instead of learning Spark notebooks for Lakehouse, this release is for you.

When we released support for Warehouse, it was limited to simple mode, but with this release, Warehouse is functionally equal with the other storage types, though still in Public Preview until we've confirmed it as production ready.

Snowflake Hosted on Google Cloud Platform

Snowflake hosted on Google Cloud Platform is now supported as Prepare instance storage, alongside Snowflake on AWS and Azure. If your organization runs Snowflake on GCP - because that's where the rest of your cloud footprint lives, or simply where your team chose to host it - you can now point Prepare directly at it. There's nothing GCP-specific to configure or learn: Prepare treats it exactly like any other Snowflake account.

Transforms for JSON and XML Data Sources

Enhanced JSON and XML data sources now have a built-in transform editor, so you can reshape a document into the tables you actually want before it lands in Ingest. Simple mode lets you pick a row path and drag fields out of the schema tree, SQLite mode lets you write SQL against the parsed document.

Streaming for Large XML and JSON Files

Large XML and JSON files are now processed as a stream instead of being loaded into memory in full. Memory use stays flat regardless of file size, so files that previously failed with an out-of-memory error during import now load.

Full Load for Data-on-Demand Sources

You can now trigger a full load on a data-on-demand data source. The flag is set per data source and carried end to end, from the step execution setup in Prepare through to the on-demand transfer in Ingest. Previously it was ignored on this path, so a full load quietly ran as an incremental one.

The Metadata Manager Tells You What Actually Changed

When a source schema changes, the Metadata Manager now shows which fields changed, in the Edit dialog and in a tooltip on the warning triangle itself. It also tells you why the Edit button is disabled instead of leaving you to work it out.

Smart Synchronization Now Treats Spaces and Underscores as Equivalent

Smart sync now matches fields between Fabric Lakehouse on Ingest and Prepare even when one side uses underscores and the other uses spaces (for example, Company_Currency vs. Company Currency). Previously this mismatch meant smart sync couldn't match these fields automatically, forcing manual mapping for every affected column.

Remap Source Data Warehouse in One Go

A new Remap source Data Warehouse... command lets you point all cross-data-area mappings in a data warehouse at a different source Prepare instance in one operation. Right-click the data area and select Advanced → Remap source Data Warehouse..., pick the Prepare instance to remap to, and review the suggested table and field matches before applying the change.

Manual Object Dependencies on Fabric Lakehouse

The Object Dependencies feature - for manually documenting relationships Timextender can't infer automatically - is now supported on Prepare instances using Fabric Lakehouse storage.

Cleanup Tool Now Removes Orphaned Fabric Lakehouse Temp Files

The DW cleanup tool now finds and lets you remove orphaned temporary files left behind in Fabric Lakehouse by notebook executions - including execution artifacts from runs that failed partway through and stray leftover parquet files - the same way it already handles obsolete tables, views, and notebooks.

Frozen Header Row in Perspectives

When you work with a long list of perspectives in Prepare and Deliver, the perspective name row now stays pinned in place as you scroll - just like freezing rows in Excel. Previously the names scrolled out of view, making it easy to lose track of which perspective you were editing.

"New" and Aligned Name and Version

As you might have noticed, the naming of this release, "Timextender Data Integration 26.3", contains two changes from previous releases. We're now using the same version numbering format as the rest of the Timextender product line and the spelling of "Timextender" - with a lower case "x" - has been aligned with our updated branding.

Fixed

Fabric Lakehouse as Prepare Instance Storage

• Fabric Lakehouse and Fabric Warehouse workspace names containing special characters (for example spaces or punctuation) could cause errors in Timextender Data Integration; those names now work correctly. Workspace names containing a forward slash (/) or backslash (\) are still not supported - this is a limitation in Fabric itself, not something this fix addresses.
• Merging a Fabric Lakehouse Prepare table across many source mappings scaled execution time with the number of sources instead of the data volume. Prepare tables with multiple source mappings now run as a single notebook execution per table instead of one per mapping, fixing the issue.
• Fixed an issue where executing a Fabric Lakehouse instance with many tables would fail once the generated notebook exceeded Fabric's 20 mb size limit.
• Business Central fields containing a forward slash in the name (e.g. "Country/Region Code") would come through correctly in Ingest but return NULL once processed in Prepare on Fabric Lakehouse.
• Lookups using NONE aggregation from the same source table could break the generated Fabric Lakehouse notebook with a code reference error.
• Fixed an error during incremental load with hard deletes enabled on Fabric Lakehouse when a Prepare table merges multiple source tables.
• A selection rule filtering on a column with special characters in its name would fail on execute.
• A custom transformation referencing a field with special characters in its name would fail on execute.
• A date table with a custom period would fail on execute due to a type mismatch between the generated notebook and the underlying parquet file.
• Running Data Profile on a table whose name contains special characters failed immediately instead of opening the dialog.
• Hash fields on a Prepare table would become null once a lookup was added to that table.
• Incremental load could fail with a KeyError when the incremental column was mapped from a system field.
• SQL snippet transformations applied to a Fabric Lakehouse table could fail deployment before it even started, even though the same logic worked as a custom value transformation.
• Opening a data area containing a field with the image datatype failed with an "Unsupported data type" error on Fabric Lakehouse.
• Remapping a table parameter in a notebook view (custom script) using "Set as..." generated an incorrectly formatted object name, breaking the mapping.
• The Query Tool didn't account for the _P suffix on persisted Lakehouse views, so running a generated query against one failed with "Invalid object name."
• Lookup transformation templates failed to deploy on Fabric Lakehouse with a null reference error. While still not supported on Fabric Lakehouse, the error is now handled.
• Enabling "Postfix valid tables with _v" on a Fabric Prepare instance broke direct data-area-to-data-area transfers with a "table not found" error. While still not supported on Fabric Lakehouse, the error is now handled.
• A boolean field with a fixed transformation could fail on Fabric Lakehouse when the source value was null, due to a data type mismatch in the generated expression.
• After pointing a Prepare or Ingest instance at a different Fabric workspace, generated notebook code kept referencing the old workspace name even after a full redeploy.
• Incremental load for the Dynamics 365 Finance & Operations connector failed in Fabric Lakehouse notebooks with an unresolved column error.

Fabric Warehouse as Prepare Instance Storage

• History-enabled tables on Fabric Warehouse could fail on execution with a data type conversion error.
• Date tables on Fabric Warehouse generated using small batched insert statements instead of a single set-based insert, causing generation of a multi-year calendar to take significantly longer than on other storage types and dominate total refresh time on smaller Fabric capacities.

Fabric Lakehouse as Ingest Storage

• Prepare read stale delta logs when queued immediately after Ingest, so a run could work from the table's previous state.
• Opening the Query Tool crashed DynamicProcessEngine_x64, which the client reported as "Service request failed: Buffer cannot be null".
• Outbound transfer threw a DirectoryNotFoundException when Handle Deletes was enabled, and did not use the primary key files to filter rows.
• Table paths for the Dynamics 365 Finance & Operations OneLake CDS source were built from workspace and lakehouse names rather than OneLake GUIDs, so they broke whenever either was renamed.
• Virtual sources reported an incremental state they could not honour, so Lakehouse incremental loads completed successfully having loaded zero rows.
• Generated notebooks are now written to a dedicated Timextender folder instead of the workspace root.

Snowflake as Prepare Instance Storage

• Fixed an issue on Snowflake where configured default column values were ignored, leaving nullable source values as NULL instead of applying the default.
• Aggregate table fields in Snowflake couldn't always be related to fields in a normal table, even with matching datatypes, due to a casing mismatch between the two.
• History-enabled tables in Snowflake could end up with multiple rows sharing the same DW_Id, and a deleted row could silently show another row's values instead of being marked as deleted.

Snowflake Data Sources

• Some dates were converted to values in the 1800s on the way into Prepare, and loading a NUMBER(38,0) column failed with a FormatException.
• Fetching views metadata over ODBC failed with "Column 'TABLE_SCHEMA' does not belong to table Views".
• The username was not quoted in SHOW GRANTS TO USER, so accounts whose names require quoting failed.
• Transient connection failures against Snowflake on AWS failed the execution outright; they are now retried.

REST and Enhanced REST Data Sources

• The REST connector could return 401 for a correctly configured request that the API itself accepted, and failed against APIs requiring TLS 1.3.
• Type inference in the Enhanced REST connector cast numeric-looking string values to integers, so a field such as "0012" arrived as 12 and broke key matching.
• Enhanced REST could not use the SharePoint scope, and decimal type overrides were ignored in favour of the source's own type.
• Setting a debug log path on an Enhanced REST data source cleared the global database settings.
• Using dynamic values in the REST connector - query parameters populated from another endpoint's table - caused execution to fail with "Cannot add a SimpleContent column to a table containing element columns or nested relations" when the response contained nested elements, and produced no debug log output. Hardcoded parameters were unaffected.
• Cloning an NTLM REST connection did not carry the password, so the clone failed with 401 until it was retyped.

JSON and XML Data Source

• The XML connector crashed with an INT64 overflow during Import Metadata on zero-padded numeric string identifiers.
• The XML connector grouped source tables by element name rather than by file, and promoted 1:1 nested elements into separate tables instead of inlining them.
• The Enhanced XML connector emitted duplicate columns per file when given a folder path, breaking creation of the raw table.
• XML table flattening failed on S3 ingest after the first XSLT, and the XML data source was missing from the ODX data source list.
• "Infer data types" on the JSON connector sized columns from the metadata file alone, causing truncation whenever real data exceeded the sample.
• JSON file aggregation named every table "Default".
• Execution hung for the enhanced JSON and XML connectors on SFTPS, and for the enhanced Parquet provider on FTPS/SFTP.
• The ODX XML and JSON connectors allowed several location settings to be edited when only one was in use.

Business Central Data Source

• Incremental load failed when the primary key columns were ordered differently on source and destination.
• Ingest from Business Central Online hung after a metadata change instead of picking up the new schema.
• The enhanced connector emitted a spurious "Selection rules are ignored on Option tables" warning for tables where the rules were in fact applied.
• An ADF copy failed with TypeConversionBooleanNotTreatedAsNumber when a Boolean Parquet column targeted a SQL tinyint, and the SQL Server Time type was converted to the wrong data type.

File Data Sources

• The Enhanced CSV connector errored when set to include incomplete rows, and incremental load with "handle primary key updates and deletes" was broken for CSV on both SQL and Fabric storage.
• An empty path or / did not work at container root, and a SharePoint Excel source failed when its path was /.
• MySQL TIME columns failed during Parquet ingest, and previewing a Parquet source failed for tables containing datetimeoffset columns on Fabric storage.
• Writing Parquet files consumed more CPU than necessary.

Qlik Cloud as Deliver endpoint

• Deploying a Qlik Cloud endpoint to a shared space created the app there but placed its data connections in the requester's Personal space instead, preventing use of a Qlik Data Gateway configured on the shared space.
• Deploying a Qlik Cloud endpoint for the first time could fail when an app with the same name already existed in Qlik Cloud without a Timextender identifier.

Other

• Incremental load silently dropped rows whose incremental column was NULL.
• The Oracle ADF data source ignored the table and column selection and brought everything across.
• Opening an ODX ingest instance failed with an XML error, and editing and synchronizing a Timextender SQL Data Source 24.3.3.0 failed with "Error creating custom data source".
• Synchronization to Prepare failed outright if table information could not be read from a virtual source, rather than reporting that one source and continuing.
• A decimal-to-int conversion failed after migration, and the SQL Enhanced data source raised a null reference error in the Query Tool.
• Migrating a Deliver instance did not update table tooltips to reflect the correct source, which was confusing when reviewing the model afterward.
• Generate End-to-End Packages and Tasks ignored an execution package's Exclude Steps, and running it for a second execution package appended that package's tables to the first package's generated perspective instead of creating its own.
• Deploying an MDW data area could fail with a circular relation error when a custom post-deployment script added role members alongside a database role configured under Security.
• The Dynamic Variable Script Editor rendered with a broken layout.