Preventing and understanding custom table build failures [Linux]
When building custom tables in Sisense, users occasionally encounter cryptic build errors referencing columns that don’t appear anywhere in their model – such as acq.acurrentXwAaquarter or aQuarters.aquarterXwAastartXwAadateXwAaint. These errors typically emerge after upstream schema changes have been made to source tables or changes/additions to custom table import queries within a complex dependency chain. This article explains two key best practices to help prevent these types of build failures and demystifies the structure of the internal column references shown in error messages.
Step-by-Step Guide:
Part 1: Best Practices to Prevent Build Failures
- When changes are made to upstream source tables in your external database, you must manually refresh the schemas in the Sisense model:
- In the Data Model Editor, click the three-dot menu next to the table name.
- Select "Refresh Table Schema".
This ensures Sisense recognizes new, removed, or renamed columns and can properly align them during the build process.
- Re-Open and Save Downstream Custom Tables. If any custom tables depend on source tables or other custom tables that have changed:
- In your Sisense data model, open the affected custom table in Edit & Preview mode.
- Confirm the SQL still parses correctly.
- Click Save to trigger a fresh internal validation of its dependencies.
Even if no changes are made, re-saving ensures that Sisense re-parses the logic and resolves dependencies correctly in preparation for the next build.
These two steps should always be performed after any upstream changes, especially in complex models where custom tables are chained together.
Part 2: Understanding Encoded Field Names in Error Messages
Sisense uses an internal system to encode complex column paths for processing. This encoding is what causes confusing references in error messages. For example:
- acq.acurrent.quarter may appear in an error message as acq.acurrentXwAaquarter
- aQuarters.start.date.int may become aQuarters.aquarterXwAastartXwAadateXwAaint
What is XwAa? This is Sisense’s internal way of flattening nested column references or handling special characters (like dots or spaces) during processing.
These encoded column paths:
- Do not appear in the schema browser or field list
- Are not searchable in the UI
- Exist only in internal SQL and error logs during build-time parsing
If you encounter these references, they usually point to a column or alias that either:
- Was deleted or renamed in an upstream table
- Is being referenced incorrectly in a downstream custom table
Understanding these encoded names can help you trace the true origin of the issue, even if the field name is not directly visible in the current model.
Conclusion
Custom table build failures in Sisense for Linux often arise from stale or broken references caused by upstream changes. These failures are preventable with two simple practices:
- Refresh the schema of source tables after any external changes.
- Re-open and save dependent custom tables to trigger revalidation.
And when errors reference unfamiliar encoded field names, remember: these are internal representations of previously valid (but now broken) field paths.
Being aware of both the prevention steps and how Sisense represents internal SQL references will help you diagnose and resolve these issues much more effectively.
References/Related Content:
