In your screenshot you put PartsOnOrder as the EpiBinding.
Is that the ID of your grid? It is, right?
In your screenshot you put PartsOnOrder as the EpiBinding.
Is that the ID of your grid? It is, right?
Do you have to establish that view before typing it into the provider model section or does typing it into this box make the view?
You will need to create it yourself first.
Yeah, I dunno. This might be bugged.
The sample shows what syntax to use, but it doesnât parse it.
I tried with another BAQ that takes a string and instead of failing, it just returns nothing. Thatâs telling me itâs taking the literal string instead of processing the value of the dynamic field.
Might be easier to just go the route of removing the parameters and using the BAQ Options WhereClause, honestly.
I donât even remember the last time Iâve used parameters; I typically just filter after the fact.
This works, btw. You can use the rest params, just exclude âParameterValueâ and make sure your BAQ parameter is set to âSkip on Emptyâ. Again, though, this is just doing the BAQ Options WhereClause route with more steps. Wellâsimilar as itâs filter after bringing back all rows. The WhereClause should filter on the server.
Ramble, ramble, ramble. Iâma go find some coffee.
I see now.
Any benefit to using the parameter though if you are using for filtering besides that the columns need to be added?
The response is just the selected record(s). The filter is done in the query with the parameter and the where.
That that Iâm aware of. I havenât used parameters in years.
This is what I am wondering, is there a performance gain using parameters vs. the where clause?
If not, I am totally cool with the whereclause optionsâŚ
Thanks again for all of your time!
Where did you get this sample?
Exactly
Depending on your version, you just hover over the field in App Studio.
I doubt it? If there is, it hasnât really been noticeable.
They should both be filtering server-side, so the client should not notice.
Alright, thank you so much for your help Hannah!