DISPLAY Action - Queries and the WHERE clause

[JonP]

This section on the DISPLAY action in the user guide drives me crazy. I need clarification:

This action is very similar to the PICK FROM action in that it displays the instances of the business object found by the action, however it does not expect the user to pick any particular instance. The syntax of the action is exactly the same as that of the PICK FROM action except that the DISPLAY keyword is used instead of PICK FROM. For example,

DISPLAY Account WHERE Account.State = 'OPEN' ORDER BY Account.Balance

My understanding is that you can use the DISPLAY action for either a BO or a query. I've never used it for a BO - I use it to run queries. It's the only way I know to how run a non-pick query from a process.

When I use it for a query, I can't use the WHERE clause because AIM says it can't find the BO. I would really love to use the WHERE clause because the process rule has access to the context, whereas I'm pretty sure the query does not (i.e. I can't use "[BO]=This[BO]" in a query's WHERE clause).

Is that understanding correct?

So far my solution for populating the query WHERE clause with instances is to add instance reference attributes to the RegularUser BO so I can use "LoggedIn", but I'm getting tired of that.

I suppose instead of a query, I can create a form in a parent BO with a single section having only a grid widget, which would simulate a query. That would allow me to use the "VIEW This[BO] USING SimulatedQuery" clause. But it just seems wrong when what I really want is a query, not a form.

Actually, it just occurs to me that using forms as queries addresses the lack of a close button in queries (which messes-up the ability to go back to the previous page). I might just abandon queries altogether! Thanks guys, this was helpful.

[JonP]

Turns out I was wrong about the context not passing into queries from a process. The WHERE clause in a query can use This[BO] even though the user's guide seems to suggest otherwise (at least that was my reading of it). Problem solved.

I'm still going to favor form grids over queries whenever possible because of their superior operation selection.

[customaware]

I'm still going to favor form grids over queries whenever possible because of their superior operation selection.

Can you please elaborate what you mean by this Jon?

[ACDC]

Whenever I have complex queries, or sometimes a simple date range in the query, I use a "query object" .
In my case I have an object called "Query" and it contains a number of attributes that I reference in my queries from time to time

Then before I run the query I create the Query object with the relevant attributes (or prompt the user to enter) and then in the query I refer to the attributes in the newly created object which is in context. It works flawlessly every time

[customaware]

That sounds intriguing.

Would love to see a small demo of that.

[ACDC]

Would love to see a small demo of that.

no need for a demo , just go to the CRM sample and check out the Process : "StaffMemberDiary" and the related Query: " Staff member calendar"

[JonP]

Code: Select all

Can you please elaborate what you mean by this Jon?

Queries have 16 panel operations vs 19 for forms. What I really care about is the Close Form operation, which if you try to replicate in Queries, does not behave in the same way (i.e. you can't return to the previous component).

Instead of "DISPLAY [query]", where possible I will find a parent BO for the BO that I want a query and use that to create a form with a grid so I can do "VIEW/EDIT [parent BO] USING [child BO query form]". That gives me the Close Form operation as well as more flexibility overall.

I'll still need queries for situations like PICK FROM, but I don't need Close Form for that.

[Jaymer]

Can you please elaborate what you mean by this Jon?

A picture (or video) is worth a 1000 words. just sayin'

[JonP]

I think you may have confused me with John Abbott, who replied the same way to you in a different post. I'm flattered.

[Jaymer]

Ha, that’s where the confusion comes from.
No, I was seconding his comment to you. Because he doesn’t get it either. I don’t get it. Mark doesn’t get it. It’s intriguing,
That’s why if you showed us an example of this fabulous methodology you’ve discovered, we would all be signing up for your class at the next symposium.

[JonP]

No problem.

In this example I have a "query" of the BO, Cycle, which is a child of the BO, Solution. I'm doing two things in this "query" I can't do in a standard query. First (and what I most care about), I have a proper close button that returns to the previous component. Second, I have an editable attribute of the Solution BO.

I call this "query" using something like "EDIT ThisSolution USING Cycles".

If I want to see Cycles across Solutions, then I would need to create a "query" in Solution's parent (Initiative) that would expand to see the cycles under each solution. Yes, you can only flatten-out the results with a standard query due to having increased control of the WHERE clause, but that's a tradeoff I'm willing to make.