CKennington
Sisense Employee
Joined 2 years ago
User Profile
User Widgets
Contributions
Preventing and understanding custom table build failures [Linux]
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: https://docs.sisense.com/main/SisenseLinux/editing-sql-statements.htm https://docs.sisense.com/main/SisenseLinux/managing-tables-and-columns.htm https://community.sisense.com/kb/troubleshooting/troubleshooting-silent-table-list-failures-in-live-models-dbt-and-external-schem/27916106Views0likes0CommentsSnowflake key-pair authentication fails when private key is owned by root [Linux]
On Sisense Linux deployments that use Key Pair Authentication for Snowflake, a connection attempt will fail if the private-key file is owned by a different Linux user (most commonly root) instead of the Sisense installation user (usually sisense, UID 1000). The Snowflake JDBC driver cannot read the key under these conditions, leading to “Authentication failed” errors in the UI and “Private key file not found or unreadable” messages in the Query service logs.69Views0likes0CommentsTroubleshooting Silent Table List Failures in Live Models (dbt and External Schema Tools) [Linux]
Users working with Live data models may report that a specific schema or database suddenly stops displaying available tables when browsing the schema. The API request (list_table_schemas) returns HTTP 200, but with an empty payload. This often occurs when external tools like dbt recreate tables or views in the data warehouse (e.g., BigQuery, Snowflake, Redshift), leaving Sisense’s metadata in a corrupted or stale state. -One or more schemas stop displaying any tables in the Sisense data model editor. -This affects a specific model, while other models using the same connection may work fine. -Exporting the .smodel file of the affected model shows inflated size compared to working models. -Duplicating the broken model preserves the issue. -Creating a new model from scratch using the same connection and data works normally.96Views0likes0CommentsTroubleshooting Application 404 Errors in Sisense [Linux Self-Hosted]
To provide both users and Sisense support engineers with a consistent approach to diagnosing and resolving unexplained 404 (Not Found) errors observed in the browser when loading dashboards, data models, or other areas of the application86Views1like0CommentsResolving Elasticube(s) not starting the build process issue
Resolving Elasticube(s) not starting to build process issue Summary This article addresses the issue where Elasticubes are not properly starting the build process and fail to produce a build error (before the initialization process can begin). Step-by-Step Instructions to Resolve the Issue 1. Identify the Problematic Elasticube: Open the Sisense application and open the data model from the Data tab. Attempt to manually trigger a build for a specific Elasticube to confirm build process does not show starting. If the build does not start, note the specific Elasticube name. Check for the existence of the build pod via the command line: Open the command line from SSH access to your Sisense server. Run this command to see a list of current cube build pods: kubectl -n sisense get pods | grep bld If a build pod exists, it will look like ec-cubename-bld. If this pod DOES exist: - verify this pod is up and in running status - verify build and management pods are up and running - recycle build and management pods together: kubectl -n sisense rollout restart deployment build management If ec-bld pod does NOT exist for your cube, there is likely a pod issue with the build or management service. - if your deployment is a single node, verify only one pod of each build and management exists (and is in up-and-running status) - likely, you have an older (build or management) pod that is stuck in a terminating or similar status - run force delete command for older (build or management) pod which does not kill itself: kubectl -n sisense delete pod <name of build or management pod> --grace-period 0 --force Monitor Logs: Review the logs for both the build and management pods to identify any errors that could provide more info on why the management service is unable to create ec-bld pod for your cube; kubectl -n sisense logs <name of management pod> | grep ERROR, kubectl -n sisense logs <name of build pod> | grep ERROR Look for patterns or recurring issues that might indicate a deeper problem. Supplementary Information Contact Support: If the issue persists after following the above steps, contact Sisense Support for further assistance. Provide detailed information about Elasticube and logs from the previous section Check out this related content: Academy Documentation845Views0likes0Comments