Hello, Has anyone had issues in the past where randomly any insight you create ends up in the following error?

SORRY, WE CAN'T DISPLAY THIS INSIGHT
Try applying different filters, or using different metrics or attributes.
If this did not help, contact your administrator.

For context, we definitely had this specific table working just fine in the past. We tried recreating the LDM entirely and reconnecting the data source, to no avail. But just nothing is working and every issues says to contact your admin (which we have). We also used the datasource scan endpoint to attempt to debug and found no warnings of any sort (

/api/v1/actions/dataSources/{dataSourceId}/scan

)

Hi @Jake Marcotte, do you see any details of error in web browser console or in response of REST API request to execute endpoint?

yeah we get this back

Please, copy&paste the traceId from the error message here, so we can copy&paste it to our logging system and find the root cause.

Hi @Jake Marcotte, our engineers have looked into the problem and root cause seems to be that some of the columns in your tables are defined as foreign keys as well as primary keys. Modeler application or generateLogicalModel API was used to create LDM and imported this definition which is causing problem to query engine now. We are considering to support this scenario in future (together with support of composite keys) but I recommend to remove primary keys based on foreign keys from your model for now. These primary keys are not visible in the modeler so you have to export the model to JSON from modeler in Data section, remove the problematic definitions of grain (primary key) and import it back from the JSON file. The problematic grain definition can be recognised by type=‘dataset’. For example:

"grain": [
 {
    "id": "dimension_table",
    "type": "dataset"
 }
 ],

should be changed to

"grain": [],

@Jakub Sterba FYI - this is also discussed in the Zendesk ticket #113304. Customer has confirmed that the proposed solution worked.

Sorry, I should have followed up here, I only did on the ticket. The above explanation is correct and the solution worked. The issue was related to having a 1-1 relationship in the database. Something to keep in mind if you also have a 1-1

Thanks for confirmation that it worked.