Change table query based on button back and forth

  • Goal: I'd like to have a table that can be filtered using a few drop down menus. However, I'd like to have a button that when clicked, changes the underlying query to another query. The two tables would have different columns.

  • Steps: I already have a working database and table that is visible to me. I've also added a search input that allows me to search for stuff in the table. This table has a query that collects data from Retool Database. I also have a switch button on top of the table.

  • Details: At this point, really what I need to do is simply figure out a way than when a switch button is clicked, the underlying query of the table is changed and the full table is updated with the new table. Moreover, if I click the button again, it switches back to the other table.

Welcome to the forum!
There's definitely a way to do this but I am wondering if it's worth the overhead and the workarounds you would need to do to make that happen.

  1. Run a query when switch is on and populate table component.
  2. Run a different query when switch is off replace temp variable data.

Here's what I think you could do:

  1. Create a new temp variable and populate it with data from query 1 after query 1 is run
    and the do the same for query 2.
    Run each query when the switch is changed.... (I set the default switch value to true
    When switch is true run query 1
    When switch is false run query 2

2.. Create a table component and set the datasource to the name of the temp variable.
Simply just set the temp variable to equal the data set from each query

You might have to set the variable value to null as an event handler in the switch and set each query event handler for query 1 and 2 to have a debounce of 500

And there could be an issue whereby the primary key for the table might need to be the same in both tables.... as I do see there is an issue when switching back and forth @Tess @joeBumbaca (Is this a bug? Or just my approach?)

Hey! Great question.

Thanks @ScottR for jumping in here. To answer your question, yes this is a known bug where the primary key cannot be dynamic :melting_face:.

@Jorge_Cimentada Tess has a great post on this, I recommend checking out. One part I'd like to highlight is dynamic columns. You may still run into an issue with primary keys so another option is to use two tables. :+1: