There is a difference though
Baq builder uses Ice.BO.DynamicQuerySvc
The Dashboard uses Ice.BO.KineticErpSvc
Does that mean anything, could there be a bug in one and not the other?
2 Likes
Okay, last suggestion before I tell you to raze it to the ground…
Create a dataview, name it,and set the type to BAQ and enter your BAQ in. Save.
Set up a panel card grid, open up the grid model, scroll down and give it an ID and set the binding to be the new view you made.
Now, throw a button somewhere and have the onClick event call the erp-baq widget and have that populate your created view. Does that work? Trying to figure out where, exactly, App Studio is throwing a fit and there are more than one way to handle this.
Although, if you really need this working, and this method is as gross as you can get, but… You could write a function to call the BAQ and convert the results to a generic dataset to pass back to App Studio and bind it that way. 
1 Like
My brain had already gone that way believe me, I was conjuring up all sorts of strange ideas to work around this but was like, NO, damn it, this should work
7 Likes
well what the shit, it now just magically works
I just did it manually and added the new shortened baq in manually and linked to the grid and it just bloody loaded, I just did it two minutes ago via the wizard and it didn’t work and now it does
4 Likes
How… unsatisfying.
1 Like
let me try manually again using the original BAQ
Wait, what…
I think I notice something, if I name the view the same thing as the BAQ it does not work
but if I name the view different to the BAQ name it works?
All the demos and docs I have show the person using the BAQ name for the data view name so you know whats what.
Seems like a red herring. I do that frequently.
1 Like
testing the theory now
Nope something is still messed up
If I use the wizards in any way then I get the error, if I do it completely manually then it works now, (it didn’t before)
I am so confused. This is still a bug in my eyes, if you use the wizard to add the BAQ it should work, otherwise the wizard is pointless.
1 Like
Now let’s do this twice, and compare the json for the app the wizard built, vs the manual.
I need to take a break and come back to this. let me go grab lunch and reset, the frustration levels are rising again.
3 Likes
Ok what we doing chief?
Side note have been able to recreate the behaviour, have one app that is manual, manual add grid, manual add data view, manual wired up, works a treat
The other created with wizard, does nothing, same error as before.
Done this twice both ways and same each time.
1 Like
In the browser tools network tab, grab the responses from both apps for the metafx->getapp call, and let’s compare
I’m not finding anything, gonna need more details.
There is a known bug in the Basic Application Wizard where if your BAQ has subqueries, the grids get created with all columns including those in subqueries that are not in your top level.
Then the way the provider model works is it runs the BAQ with a select list of columns and because of the above this can now cause the SQL error you are seeing because the columns do not exist to the top level.
Therefore when this happens you need to your grid after the app has created and go to Grid Model > Columns and review the list of columns and delete any that are not in your top level. Alternatively I believe you can now (depending on version) use the grid wizard to run through the column set up again.
Are those columns it is erroring with in your top level? If not delete them out of the grid and try again.
14 Likes
You, are absolutely correct.
This is exactly what is was, which also means that my hunch that it was a bug was correct too.
Went in and had a look at the columns and the ones from the subqueries where included. removed them and now it works.
2 Likes
How can that be it’s stateless… 
4 Likes