Skip to main content

Community Feedback
Chapters
Events
Forums
Blogs
KB Docs
Support
Learning
Use Case Gallery

All Posts Discussions Blogs Ideas Questions

Categories

Troubleshooting | Sisense Community

Knowledge Base Docs

Troubleshooting

Created Apr 15, 2026

1 member

156 discussions

Troubleshooting Tips and Tricks

Troubleshooting
Fact and dimension relationship not allowed because a join field is greyed out[Linux]
Introduction: When building a data model, you try to connect a field in a fact table to a field in a dimension table, but the field you want to join on appears greyed out and Sisense does not let you create the relationship. This most often happens when the two columns you are trying to join have different data types. Step-by-Step Guide: When you try to connect a key in a fact table to a key in a dimension table and the target field is greyed out, Sisense could not create the relationship because the two columns have different data types. Sisense only allows a relationship between columns whose data types match. The steps below align the types so the join can be created. Step 1: Identify the two key columns. Open the data model and locate the field in the fact table and the field in the dimension table that you want to join (for example, Fact.AssessmentId and the dimension's AssessmentId). Step 2: Compare the data types. Check the data type of each key column. A mismatch - for example, one column being text/string and the other numeric, or two numeric types of different width — is what causes the field to be greyed out. Step 3: Standardize the data type on both sides. Change the type so both key columns match. In the reported case, casting the key to BigInt resolved the issue. You can do this with a custom column expression, or correct the type at the data source. SQL (custom column expression): CAST([AssessmentId] AS BIGINT) Step 4: Fix custom tables at the query level. This also happens with custom tables when two columns produced by the table's query have different data types. Because the types come from the query, open the custom table, review its query, find the two columns used in the join, and cast both values to the same type so they align. SQL (custom table query): SELECT CAST(a.AssessmentId AS BIGINT) AS AssessmentId, CAST(b.EntityId AS BIGINT) AS EntityId FROM ... Step 5: Rebuild and create the relationship. Rebuild the affected table(s) so the type change takes effect, then return to the model editor and create the relationship. The previously greyed-out field should now be selectable. Conclusion: Key takeaways: A greyed-out join field almost always means the two key columns have mismatched data types. Align the data types on both sides of the key (for example, cast both to BigInt), then rebuild the table. For custom tables, fix the mismatch inside the table's query by casting both columns to the same type. If types already match and the field is still greyed out, confirm both columns exist, are not hidden, and that a valid join path is detectable. References/Related Content Data Model Building Practices for Business Intelligence - Sisense product documentation.
Ihor YokhymPosted 3 weeks ago
0
Troubleshooting
After a server reboot, connectors hosted by Sisense.CLRConnectorsContainer stop working with Event ID 7000 / 7006 [Windows]
WindowsData ConnectorsData ConnectionHow-ToTroubleshooting: Windows
Introduction: After a Windows server reboot, the Sisense.CLRConnectorsContainer service fails to start (Windows Event 7000 / 7006), so its connectors (e.g. Microsoft SQL Server) stop working — causing build failures, Live dashboard errors, and connectors missing when adding tables. This guide resolves it by extending ServicesPipeTimeout. Applies to Sisense on Windows (on-prem), all versions. Step-by-Step Guide: Customers usually notice this issue through one or more of the following symptoms after a server reboot: ElastiCube builds fail on cubes that use a CLR-hosted connector. Dashboards using Live data models return errors, because live queries cannot reach the connector. When adding a new table to a data model, the connector does not appear in the list and cannot be selected. The root cause is that the Sisense.CLRConnectorsContainer service failed to start during server startup. In the Windows Event Viewer (Windows Logs → System), you will find events such as: Event ID 7000 — "The Sisense.CLRConnectorsContainer service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion." Event ID 7006 — "A timeout was reached (30000 milliseconds) while waiting for the Sisense.CLRConnectorsContainer service to connect." The Windows Service Control Manager (SCM) requires each service to respond within a default window of 30 seconds (30000 ms), controlled by the registry value ServicesPipeTimeout . After a reboot, all services start at once and compete for CPU and disk I/O; combined with the CLR container initializing many connectors, the default window is often exceeded, the service times out, and its connectors become unavailable. Resolution — extend the SCM service start timeout This value applies server-wide (to all services). Caution : Editing the registry affects the entire system. Back up the target key first and, where possible, perform the change during a maintenance window. Administrator privileges are required. Log on to the server with administrator privileges. Launch regedit (Registry Editor) as administrator. Navigate to the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control (registry path) Check whether a DWORD value named ServicesPipeTimeout exists in the right pane. If it does not exist, right-click the empty area → New → DWORD (32-bit) Value, and name it ServicesPipeTimeout. Double-click ServicesPipeTimeout to open it. Set the Base to Decimal . Enter the extended timeout in milliseconds. Recommended: 180000 (180 seconds). For environments with longer startup times, increase up to 300000 (300 seconds). Click OK to save. Restart the server to apply the change ( the SCM reads ServicesPipeTimeout only after a reboot ). After the restart, confirm that Sisense.CLRConnectorsContainer starts successfully and that Event 7000 / 7006 no longer recur. Optional — mitigate via startup order (can be combined) If services contend during a simultaneous startup after a reboot, set non-core services to Automatic (Delayed Start) so foundational services (Mongo, Zookeeper, RabbitMQ) start first, reducing the chance of a timeout. This works well combined with extending ServicesPipeTimeout. Conclusion: The Sisense.CLRConnectorsContainer failing to start after a reboot is caused by the Windows SCM default 30-second start timeout being exceeded under startup contention. Increasing the ServicesPipeTimeout registry value (e.g. to 180000 ms) and rebooting gives the service enough time to initialize, keeping its connectors available and preventing build failures, Live dashboard errors, and missing connectors. Setting non-core services to delayed start further reduces the risk. References/Related Content Microsoft — A slow service does not start due to time-out error in Windows . Disclaimer : This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
Eiji OzawaPosted 1 month ago
0
Troubleshooting
Resolving resize widget Issue when the Tabber Widget is in use
Add-OnsConfiguration & Design Tipstraining
Introduction When using the Tabber widget, you may encounter issues where other widgets cannot be resized. This guide provides a step-by-step solution to resolve the problem by temporarily removing and recreating the Tabber widget while ensuring all widgets remain functional. Step-by-Step Guide Identify the Problem: Confirm that the issue is with the Tabber widget not allowing the resizing of other widgets on the dashboard. Delete the Tabber Widget: Before deleting the Tabber widget, copy any scripts associated with it. Remove the Tabber widget from the dashboard. Resize the Widgets: Resize the other widgets on the dashboard as needed. Ensure that the widgets are properly sized before re-adding the Tabber widget. Recreate the Tabber Widget: Add the Tabber widget back to the dashboard. Paste the previously copied script into the new Tabber widget. Verify the Solution: Check if the resizing issue is resolved in the duplicated dashboard. Ensure that the Tabber widget and other widgets are functioning correctly. Troubleshooting Tips Edit Mode Issues: If you cannot change the size of widgets in edit mode, try adding another widget next to the one you want to resize. This can sometimes resolve resizing issues. Conclusion By following the steps, you can restore full resizing functionality. If issues persist, try adding another widget nearby as a workaround. This ensures a smooth and flexible dashboard layout.
Sisense UserPosted 2 years ago • Last reply 1 month ago
3
Troubleshooting
Resolving the Entra ID AADSTS75011 error during SAML SSO [Linux]
Introduction: Experiencing the AADSTS75011 error during Microsoft Entra ID SAML SSO? This occurs when Entra ID rejects Sisense's password authentication request in favor of MFA or Windows Hello. Learn to update your SSO configuration to prevent this mismatch. Applies to all recent versions, Cloud and On-Premises. Step-by-Step Guide: When Sisense performs a SAML authentication request by default, it includes the RequestedAuthnContext parameter, which specifically asks Entra ID to authenticate the user using a standard Password method. If your users authenticate with higher-security methods (like Windows Hello, MFA, FIDO2, or certificate auth), Entra ID rejects the mismatch and throws the AADSTS75011 error. To resolve this, you must set the PassAuthnContext parameter to false in Sisense's SSO settings. This tells Sisense to omit the strict authentication context, allowing Entra ID to authenticate the user based on your organization's security policies. Step 1: Access the REST API Explorer Log in to Sisense as an Administrator. Navigate to Admin → REST API via the left-hand menu.

Description: The Sisense Admin page with the REST API tab highlighted in the left navigation pane. Step 2: Switch to API Version 0.9 To ensure this specific system setting change persists properly in the database, you must use version 0.9 of the API. At the top of the API Explorer page, locate the version selector. Change the selection from 1.0 (or v1) to 0.9. Step 3: Apply the Configuration Payload Scroll down and click on the POST /settings/sso endpoint to expand it. Click the Try it out button. In the body parameter field, paste the following JSON payload exactly as shown below: { "saml": { "PassAuthnContext": false } } Click Execute .

Description: The expanded POST /settings/sso endpoint showing the JSON payload in the request body and the Execute button. Step 4: Verify the Change Check the Server Response section directly below the Execute button. You should receive a 200 OK response code, indicating the system setting was successfully updated. Once applied, users should no longer receive the AADSTS75011 error. (Note: Users experiencing cached redirects may need to clear their browser cache and cookies for "All time" if the error temporarily persists). Conclusion: By updating the PassAuthnContext flag to false via the 0.9 REST API, Sisense stops enforcing a specific authentication method in its SAML payload. This resolves the AADSTS75011 mismatch error and allows Microsoft Entra ID to successfully process MFA, certificate, or passwordless logins seamlessly. References/Related Content : How to generate a HAR file with sensitive data (Windows/Linux) - Useful if further SAML troubleshooting is required. Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
Taras SkvarkoPosted 3 months ago
0
Troubleshooting
Resolving "SELF_SIGNED_CERT_IN_CHAIN" errors in Sisense SSO integration [Linux]
Introduction: When configuring Single Sign-On (SSO) using OpenID Connect or SAML with a self-signed Identity Provider (IdP) certificate, you may encounter SELF_SIGNED_CERT_IN_CHAIN errors. This guide explains how to resolve these strict TLS validation failures in both Sisense Cloud and On-Premises (Linux) deployments. Step-by-Step Guide: 1. Identifying the Issue Users attempting to log in via SSO may see a generic error in the UI. To confirm the root cause, you need to check the Sisense logs for an InternalOAuthError caused by a missing trust chain. Sisense Cloud: Use the System Management UI to generate and download the support logs. Open the downloaded archive and search the combined.log file for the error. On-Premises (Linux): Access your server via SSH and run the following command to check the identity pod logs directly. kubectl -n sisense logs -l app=identity --tail=100 Text (Error Output Example): Error: Authentication failed: InternalOAuthError: failed to obtain access token ... oauthError: Error: self-signed certificate in certificate chain ... code: 'SELF_SIGNED_CERT_IN_CHAIN' 2. Prepare the Certificate Sisense must be provided with the Root CA (and any Intermediate CAs) that signed your IdP's certificate so the application can establish a full chain of trust. Ensure your CA certificate is exported in a Base64-encoded X.509 format. The file must have a .crt or .pem extension. Text (Certificate Format Example): -----BEGIN CERTIFICATE----- MIIE...[Base64 encoded string]... -----END CERTIFICATE----- 3. Add the Certificate to the Trusted Store & Recreate Pods The steps to apply the certificate differ depending on your environment: For Sisense Cloud Users: Navigate to the File Management section in the Sisense System Management UI. Upload your prepared .crt or .pem file directly into the custom-certificates folder. Services usually restart automatically in the background when a file is uploaded here. However, if the issue persists after a few minutes, a manual pod recreation is required. Please reach out to Sisense Support , and they will perform a clean pod recreation for your environment. For On-Premises (Linux) Users: Transfer your .crt or .pem file to your Sisense server and place it in the designated custom certificates directory: /opt/sisense/storage/custom-certificates/ A standard service restart is sometimes not enough to trigger the initialization scripts that mount new certificates. You must force Kubernetes to recreate the pods manually by running the following commands: kubectl delete pod -n sisense -l app=identity kubectl delete pod -n sisense -l app=api-gateway 4. Verify the Fix For Cloud Users: Open an incognito browser window and attempt the SSO login again. If the login succeeds, the certificate is trusted. For On-Premises Users: Wait for the new pods to reach a Running state. You can verify the certificate is now trusted by running a curl test from inside the new identity pod. kubectl exec -it $(kubectl get pods -n sisense -l app=identity -o custom-columns=":metadata.name" --no-headers | head -n 1) -n sisense -- curl -v https://your-idp-url.com If the command succeeds and returns an HTTP response (e.g., HTTP/1.1 200 OK) instead of an Exit Code 60 SSL error, the trust chain is successfully established, and your SSO login will work. Conclusion: Ensuring Sisense explicitly trusts your IdP's custom or self-signed certificate is crucial for successful SSO integrations. By verifying your certificate format, placing it in the correct directory, and ensuring the associated pods are properly recreated to load the new files, you can quickly resolve underlying TLS handshake failures and restore user access. References/Related Content Custom Certificates in Sisense on Linux Uploading Files to Customize Your Linux Deployment Generating Support Log Files Single Sign-On using OpenID Connect Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
Taras SkvarkoPosted 4 months ago
0
Troubleshooting
How to generate a HAR file with sensitive data [Windows][Linux]
Introduction: Following browser updates in late 2024, Chrome and Edge now sanitize HTTP Archive (HAR) files by default, removing cookies and authorization headers. This guide explains how to re-enable sensitive data capture to provide comprehensive logs for advanced troubleshooting. Applicable to: Chrome and Edge browsers (Version 129+). Step-by-Step Guide: 1. Enable Sensitive Data Export in Settings Before recording your logs, you must grant the browser permission to export sensitive information. For Microsoft Edge: Open Developer Tools (Press F12 or Ctrl+Shift+I). Click the Network tab. Click the three dots (...) in the top right corner of the DevTools pane and select Settings. For Google Chrome: Open Developer Tools and navigate to the Network tab. Click the Gear (Settings) icon located in the top-right toolbar of the Network tab. 2. Configure Preferences Under the Preferences menu, scroll down to the Network section. Check the box labeled Allow to generate HAR (with sensitive data). 3. Record and Export the Log Return to the Network tab. Ensure Preserve log and Disable cache are both checked. Click the Clear icon (null sign) to start with a fresh log. Reproduce the issue in the browser window. To export, long-press (click and hold) the Download (downward arrow) icon. Select Export HAR (with sensitive data)... from the menu. Conclusion: Generating a HAR file with sensitive data ensures that support teams can see the exact cookies and headers causing authentication or session-related issues. Always remember to disable this setting or handle the resulting file securely, as it contains private session information. References/Related Content WPO365: Create a HAR file with sensitive data Google Chrome DevTools Documentation Disclaimer:This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
Taras SkvarkoPosted 4 months ago
0
Troubleshooting
Solving the "Zombie Connection" Race Condition in Istio/Envoy [Linux]
Introduction: If you are running Sisense on Kubernetes with Istio (ASM), you may encounter intermittent 502 Bad Gateway or 503 Service Unavailable errors during JAQL queries, even when your pods appear healthy. Step-by-Step Guide: 1. The Problem: Timeout Mismatch By default, the Istio Ingress Gateway (Envoy) tries to keep TCP connections to backend pods alive for as long as possible (defaulting to 1 hour). However, the underlying GCP VPC network or the Sisense application pods often have much shorter idle timeouts (usually 60 seconds). This discrepancy creates a race condition: A connection sits idle between dashboard refreshes. The Sisense pod or the GCP network closes the connection due to age. At that exact microsecond, Envoy attempts to reuse that "established" connection to send a new JAQL request. Because the other end is already closed, Envoy receives a TCP Reset (RST). Log Examples In your Istio Ingress Gateway logs, you will see the following flags: 503 UC: Upstream Connection termination. 101 DC: Downstream Disconnect. 2. The Solution: EnvoyFilter Alignment To fix this, you must force Envoy to be more "aggressive" than the network. By setting Envoy’s idle_timeout to 45 seconds, Envoy will proactively kill its own idle connections before the GCP network or the Sisense pod has a chance to drop them silently. Critical Implementation Detail Many users attempt to apply the filter in the application namespace (e.g., sisense), but if sidecar injection is not enabled, that filter will do nothing. The filter must be applied where the Envoy proxy actually lives: the istio-system namespace. The Fix Apply this configuration to target the Ingress Gateway specifically: apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: sisense-idle-timeout namespace: istio-system # Must be in the same namespace as the Ingress spec: workloadSelector: labels: app: istio-ingressgateway # Targets the Gateway proxy configPatches: - applyTo: CLUSTER match: context: GATEWAY patch: operation: MERGE value: common_http_protocol_options: idle_timeout: 45s # Closes connection before the 60s VPC/App limit Conclusion: This ensures that the Ingress Gateway the only Envoy proxy in a non-sidecar setup manages the connection lifecycle properly. By "hanging up" first, it prevents the use of "zombie" connections, eliminating the 503 UC resets. Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
Liliia KislitsynaAdminPosted 6 months ago
0
Troubleshooting
Minimum Information Required for a Sisense Support Ticket
When submitting a ticket to the Sisense Support Team, please always aim to provide clear, categorized details regarding your issue. By supplying all possible answers upfront, you eliminate the need for back-and-forth communication, allowing our engineers to begin investigating and resolving your issue immediately. Ensure you include the following: 1. Problem Definition (What is the problem?) Clear Description: Explain the issue and the functionality that is failing. Expected vs. Actual Results: Clearly state what you expected to happen versus what actually happened. Steps to Reproduce: Provide a specific, step-by-step guide on how the support engineer can replicate the issue. Visual Proof & Network Traffic: Attach uncropped screenshots or screen recordings showing the error or behavior. For web interface issues, please also attach a HAR file (see: Generating a HAR file for troubleshooting Sisense ). 2. Scope and Business Impact (Who is affected?) Affected Users/Dashboards/Cubes: Note whether the issue impacts all users, a specific user group, or just a single user. What is unique about the affected group? Does the problem occur across the entire platform, or only on specific dashboards or ElastiCubes? 3. Frequency and Pattern (How often does it occur?) Timeline: Exactly when did the problem first occur? Did it ever work as expected in the past? 4. Environment and Recent Changes (Did something change?) Recent Events: Did the issue start after a specific event, system change, or Sisense version upgrade? Load Changes: Has there been a recent increase in the number of users, data volume, or concurrent builds? Infrastructure Health: Do you observe any infrastructure utilization outliers (e.g., spikes in CPU or RAM) during the occurrence of the problem? For Cloud Customers: Provide the URLs to the affected Dashboard/ElastiCube and, if possible, relevant usernames support can use to troubleshoot. Please make sure the Support Access is enabled on the instance. 5. Technical Artifacts (Logs for On-Premise Customers ) Always attach the relevant server-side logs based on the issue. Identifying the Service: If you are not sure which service is affected, use the Sisense Linux Services Guide or Guideline for collecting troubleshooting logs . The log name corresponds directly to the service name. Extracting Logs: For step-by-step instructions on pulling these files, see: How to identify and download logs from the Sisense server . By packaging your problem description, business impact, recent environmental changes, logs, and a HAR file into your initial request, the Sisense team can bypass the standard fact-finding phase and begin actively resolving your issue immediately.
Liliia KislitsynaAdminPosted 7 months ago
0
Troubleshooting
Elasticube stuck in "saving files" phase and unable to build cube [Linux]
Step-by-step guide When building an Elasticube in Sisense Linux, the process may halt at the “Initializing,” “Saving files,” or “Attaching cube” stages, especially after manually cancelling a build. Standard service restarts do not resolve these stuck states. 1. Check RabbitMQ queues for stuck messages Sometimes, message queues hold up the completion of the build. Command (bash): kubectl -n sisense exec -it sisense-rabbitmq-0 -- rabbitmqctl list_queues --formatter pretty_table | grep -v 0 Review the output for queues with unexpected message counts. Screenshot: Terminal with rabbitmqctl command output highlighting nonzero queues. (Description: Output showing a queue with many pending messages that may indicate blockage.) If stuck messages are found, consider purging the queue. 2. Identify and remove stuck cube build entries in MongoDB Persistent build entries can block new builds. Find your MongoDB pod: kubectl -n sisense get po | grep mongo Access the MongoDB pod: kubectl -n sisense exec -it <your-mongo-pod-name> -- bash Enter MongoDB shell: mongosh Switch to Sisense's 'be' database: use be Find running build entries: db.buildLogData.find({status:"RUNNING"}) (Description: Output should show records with your cube’s name and running status.) Delete stuck builds for the specific cube (replace 'cube name' accordingly): db.buildLogData.deleteMany({'dataSourceTitle.value':'cube name'}) 3. Retry the cube build Return to the Sisense UI and try building the cube again. Troubleshooting Tips Double-check the cube name before using the MongoDB delete command. Always back up your database before performing direct deletions. For multiple stuck cubes, repeat the deletion process for each one. If problems persist, review Sisense system logs and reach out to Sisense Support. Conclusion Sisense cube builds can get stuck in “Saving files” due to residual process states, especially after manual cancellation. Clearing RabbitMQ queues and removing “RUNNING” build entries from MongoDB resolves this for most users. Always exercise caution when making database changes. References/related content Build Log Walkthrough How To Troubleshoot Build Failures (Linux OS) Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
oleh_dukhPosted 9 months ago
0
Troubleshooting
Troubleshooting ElastiCube build failure: SQL MALException !ERROR: GDKsave: failed name [Linux]
Step-by-Step Guide: 1. Understand the error Error Example: 9500 | ElastiCube error Check the farm validity and try recovering the last successful build. Try rebuilding the cube. BE#211715 Failed to create table: <table_name>. SQL: MALException:!ERROR: GDKsave: failed name=<id>, ext=tail, mode 0. Root Cause: The most common cause is a low open file limit (LimitNOFILE or LimitNOFILESoft) for the containerd service, which prevents the database engine from saving files during the build process. 2. Check and Increase Open File Limits A. Verify Current Limits Run the following command on your Sisense server: sudo systemctl show containerd | grep LimitNOFILE If you see values like LimitNOFILE=1024 or LimitNOFILESoft=1024 , this is too low. B. Update containerd Service Limits Edit the containerd service configuration: sudo systemctl edit containerd Add or modify the following lines in the [Service] section: [Service] LimitNOFILE=524288 LimitNOFILESoft=524288 Save and exit the editor. C. Reload and Restart containerd Reload the systemd daemon: sudo systemctl daemon-reload Restart containerd: sudo systemctl restart containerd D. Confirm the New Limits Run: sudo systemctl show containerd | grep LimitNOFILE You should see both values set to 524288 . E. Recreate Affected Pods For changes to take effect in running pods: kubectl -n sisense delete pod <build pod-name> Verify inside the new pod: kubectl -n sisense exec <build pod-name> -- bash -c "ulimit -Sn && ulimit -Hn" Expected output: 524288 524288 3. Retry the Elasticube Build After applying the above changes, attempt to rebuild the Elasticube. The error should be resolved if the open file limits were the root cause Conclusion The SQL: MALException:!ERROR: GDKsave: failed name error is typically caused by insufficient open file limits for the containerd service. Raising these limits resolves the majority of cases. References/Related Content Sisense Linux Build Logs Overview Managing Linux Build Service Settings Troubleshooting Build Failures Due to Memory Issues (Safe Mode) Steps to Do Before Contacting Support Regarding Build Failures Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
oleh_dukhPosted 9 months ago
0
Troubleshooting
Data indexing error: Dim table corruption found on dimension table [Linux]
Step-by-Step Guide: This error arises due to Sisense’s internal build validations, specifically the RelationDimTablesValidation check. This validation ensures all dimension tables used in table relations contain all possible key values, maintaining data integrity during query execution. More details on these checks are available in the Sisense documentation . Recommended Solutions: Enable Build Retry: Automatically retry builds after a failure to resolve temporary issues without manual input. How to enable Build Retry: Navigate to: Admin > System Management > Configuration Unlock additional build settings: Click the Sisense logo 5 times. Enable build retry: Set RetryBuild.value = true. How Build Retry works: The NumberOfBuildRetries parameter defines how many automatic retries occur after a failure (default is 0, meaning no retries unless set). When enabled, only the latest build logs remain after a retry. Configuring retry parameters: Set NumberOfBuildRetries (number of attempts). Set WaitTimeAfterBuildFailedBeforeRetry (default: 60 seconds). Click “Save Changes” to apply. Disable Validations; If retries do not help and the error persists, disable specific validation checks one-by-one to identify the problematic one: DataIndexingValidation RelationDimTablesValidation IndexingDimTablesValidation How to disable validations: Go to: Admin > System Management > Configuration Click the Sisense logo 5 times to unlock hidden settings. Scroll to the Build section. Set the relevant validation flags to false . Save changes. Conclusion: Sisense’s data integrity checks are designed to prevent the use of inconsistent data. If you encounter error 9300 related to dimension tables, enabling build retries or selectively disabling validations can resolve these issues. Always track changes and test in your environment before applying these solutions broadly. References/Related Content Sisense Build Logs Overview Building ElastiCubes L2024.3 Release Notes Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
oleh_dukhPosted 9 months ago
0
Troubleshooting
Dashboard dates display incorrect years due to fiscal year settings [Linux]
Step-by-Step Guide Check your Elasticube fiscal year start month Open Sisense Admin or Elasticube Manager. Navigate to the Elasticube used by the affected dashboard. Locate the Fiscal Year Settings section. 2. Review the fiscal year start month Verify the month configured as the Fiscal Year Start Month. If set incorrectly (e.g., April instead of January), Sisense shifts dates into the next fiscal year, causing dashboards to display dates one year ahead. 3. Adjust the fiscal year start month If the setting is incorrect, change it to the correct start month (typically January, unless your organization uses a non-standard fiscal year). Save your changes. Conclusion Incorrect dashboard dates often result from misconfigured fiscal year settings in the Elasticube. By reviewing and updating the fiscal year start month and rebuilding the model, you can quickly restore accurate date displays across your dashboards. References/Related Content Sisense Documentation: Fiscal Year Settings: https://docs.sisense.com/main/SisenseLinux/fiscal-years.htm
Ihor YokhymPosted 10 months ago
0

…