Tim's avatar
Tim
Data Integration
03-26-2024
Status:
Needs Info

Refresh schema for all tables

Can we get a "refresh schema for all tables" button?

Reason:
Our tables are usually "Select * From AnalyticsSchema.ViewName". We control which fields to return by editing the view, not the Sisense table definition. When a field gets added/removed/changed, we need to refresh schema. That's fine to do manually as you're working on that datamodel+views, but we need to refresh all when:

  • We copy a datamodel to a different server. We need to refresh schema at least to double-check that the views are as expected on the new server. (If any fields have changed, then I'll need to go fix any widgets using those fields, or, more likely, update the view to include them.)
  • A view gets edited, perhaps for a different datamodel, and my datamodel hasn't been updated. 
  • I edit several views and want to refresh schema for all those Sisense tables. If I've changed used fields then I'll need to go into each table manually anyway so it doesn't matter, but I've had a case where I've removed unused fields from several views and now I need to click refresh schema on every table individually.
Data Models

14 Comments

Show More
  • LOV122333's avatar
    LOV122333
    Data Storage
    04-03-2025

    I am trying to refresh the game app schema for all tables, but after doing so, my page still shows the previous structure of the tables. The new columns and changes made to the schema are not showing up on the page.

    Possible Causes:

    There may be an issue with the table mapping, where the refreshed schema hasn’t been correctly applied to the relevant pages.

    The table structure might not have been saved properly before attempting the refresh.

    Permissions might be restricting the visibility of the updated schema to the user’s account.

  • Tim's avatar
    Tim
    Data Integration
    04-21-2025

    Hi Lonaav2122

    I usually create views in my database that return what I need in Sisense, then in Sisense just select from those, instead of selecting from tables or writing queries in Sisense.  Those views select columns explicitly, not *. You might like to also throw in cast-as-datatype statements so the datatype doesn't change unexpectedly.

    That way, the columns returned change only when you do it deliberately, so when you refresh schema you already know whether columns are changing. If the underlying tables change, then your views return an error. You have to go point them at the new column names.

    Using views also means you can re-use the same views in other data models, analytics tools, queries and views, and you can manage it all in SQL instead of in the data model. That does have the downside that if you want to change a view you have to find and test every data model that depends on it, but for us the upsides outweigh the downsides, and we use conventions, documentation, and automation to help.

    It's best if you can query a database that doesn't keep changing columns. But that might not be practical. Are you querying views built for other reports that other people change when they modify their report? I've sometimes started a data model that way, but then copied their query into a new view for my report.