I have a ListView with a checkbox that must obtain it's value from a SQL query (but not the query that populates the ListView itself). In order for that to work another value in the same ListView row must be passed to the query. I have tried two methods, the second in an effort to debug.
I embedded the expression that contains [i] directly into the SQL.
I made that expression the value of a textbox inside the listview and then embedded {{magic_hidden_box}} in the SQL.
This all "works" in the sense that for row 0 the evaluation of these expressions produces the correct answer. And row 0 displays it correctly.
The problem is that the same results are applied to rows 1-n in the ListView as well. Not Good.
Somewhere along the way I ticked the box "cache the results of this query" and I was thinking Ah Ha! That's the problem. But no. Turning caching off had no effect.
I thought this was the whole point of the [i] and it's magic qualities. Is it even supposed to work? Is this a known trouble spot? Are there debugging tips?
Update: I noticed that a different query where Action Type is Update a record, or create a new record if it doesn't exist is working correctly. This query is over the same table it is just not a read query. So the read query fails and the write query does not fail.
There is a delete query as well. So I just retested and:
- Inserts work. Action Type: Update a record, or create a new record if it doesn't exist
- Updates work. Same query as Inserts.
- Deletes work. Action Type: Delete a record
Only read fails. The Action Type concept does not exist. It is just a raw SQL select.
Happy to help you untangle this! Would you mind sharing some screenshots of your current config? Anything showing your query data or your component value inputs would be great.
Here is the query where [i] is not working.
I "fixed" the problem with this. Basically I get every possible row for the ListView and search for the data I need at each [i]. Of course the Javascript is super ugly but I suppose the single DB read is more efficient anyway.
Oh, very glad to hear it! If it’s not working for you (if it’s slow, not fully functional, etc), happy to help think of another way to achieve this. Though, that’s probably just about how we’d solve this as well 
So are you saying "by design" the [i] notation does not work in read queries?
I am definitely having some performance issues but not related to this. I will post a separate ticket for that.
The i variable, when using it outside of the List View, isn't actually defined until the List View component passes it in. The List View passes i into a query when that query gets triggered from somewhere in the List View (e.g. a button in the list view).
Previewing the query that uses i works because i, when undefined/not passed in yet, uses a default value of 0 only in preview mode of the query.
So basically, clicking Run on a query that uses i won't work. You'll need to trigger the query from the List View first!
In this case there is no triggering from a button inside the listview. The query that needs the i parameter is just delivering data used to display a control inside the listview. But the "triggering" event is the display of the entire listview itself.
Ah, then could you create a JS loop and use an i variable from that instead? Or maybe even something like this?
I had to abandon using ListView because of performance issues so I never bothered to test out this idea. Sorry 'bout that.
No worries at all and I’m sorry to hear you ran into performance issues. Let me more if there’s anything I can help with there!
