Report from Query Design Question

Imagine this situation.

You have a BO of 1,000 Employees for example.

You have a listing Report (Native Aware with Query Determined at Runtime)

You want your end users to be able to Filter by any number of Attributes such as Surname, Date Range for Date of Birth, Gender, Department or whatever.
You also want your end users to be able to sort them in any way they want. For example by Department ASC, Gender ASC , Surname.

Then you want to generate the listing Report with just the records that have resulted from the Filter and in the Order defined by the user above.

How do you do it?

Just as an additional point.

In my head.... you display a query with all the records displayed.
Use Top Panel Filters to reduce the records to the desired subset.
You then sort the way you want by clicking Column Headers (of course this only sorts by the Column you have click rather than a composite sort of different Columns)

You check the records of the subset you want to print.

This only works in V6 (ie. Sort Order preserved in the Report)

In version 7.x it does not honour the sort order of the Query.

Hence, looking for an alternative method that preserves the sorted order in the report.

what about if the selected instances were saved in a BO, wouldn't they be saved in the order in which they appear on screen?
Then access them from there.

That's and option Mathew.

Not very elegant but might work.

Will try it out.

pureist wrote

what about if the selected instances were saved in a BO, wouldn't they be saved in the order in which they appear on screen?
Then access them from there.

Not necessarily! How internally they're read to display and how internally they're read to process, i.e. save to to DB is different. Saving to DB resulted very random looking to me at one case. I had to create my own seq. # to give it some sense. It throw me off a bit for a while.

Well, if that's the case in this case, then each instance could be added to the non-persistent 'report data BO' as it is selected, or deleted as it is unselected.

pureist wrote

Well, if that's the case in this case, then each instance could be added to the non-persistent 'report data BO' as it is selected, or deleted as it is unselected.

Non-persistent BO can not handle collection (multi objects) properly. I wasted two weeks to find out it only stores single object in memory, not a collection.

Do you mean it only stores a single instance in memory?
Or do you mean it will only store a single object which can have many instances?

pureist wrote

Do you mean it only stores a single instance in memory?
Or do you mean it will only store a single object which can have many instances?

Good question. The first one, a single instance of an object.
You could have many none-persistent object created, but each one can only have one instance. If you assign multiple instance, if I remember correctly, you would end up seeing the "Last" one added. I might be wrong the "First" or the "Last". Forgot!

Unless I have been doing something wrong, from my experience it can only retain a single instance of a BO in context at any one time.

Mark,

Once you have the instances filtered, would it be workable for you to offer a list of sort options for the report rather than sorting them first on the query?

Thought about that Tom but I can think of a way to stuff what the user chooses into the Report Query dynamically.

Firstly there is no way to build a Query dynamically for Determined At Runtime (which is necessary as it uses the selected and filtered records of the Query)
And, even if you could I know of no way to do something like this....

SELECT MyBo WHERE Blah, Blah, Blah ORDER BY <<LoggedInRegularUser.MySortOrder>>

BUT

I have just had a brick fall on my head which has initiated a Brain Wave.....

Will report back on the progress with the Flux Capacitor!

Well, I found a way but it is not suitable as it involves setting the ORDER BY for the Employee regardless of who is using the system.

It mean if User A set the ORDER BY to FamilyName then User B's ORDER BY will also be FamilyName.

Fail!

I would create a special Object for this report, and then after prompting the user for parameters and sort order create an object for each item in the report .(also each object would contain a sequence number related to the sort order)

......Much the same as you would do for a complex Chart where a single object is created for each point in the chart.

So every time the user runs the report a new set of objects are created. The objects obviously become obsolete after the report has been generated and can be deleted by a separate process at some time.

Alternatively, if you could address the sort order in the query by way of a tag , I was going to suggest creating a Range object for the purpose of the query. So the query would be run from a process where a single Range Object is created prompting the user for the parameters and then reference the Range object (which is in context) in the query. So every time a report is run a new Range object is created for the purpose of the query parameters - but the sort order breaks this idea

Unless I have been doing something wrong, from my experience it can only retain a single instance of a BO in context at any one time.

Are you sure?

Attached is a simple BSV with 1 process that creates 2 instances of a non-persisted BO and accesses both multiple times.

Maybe it works because it is so simple.

BobK wrote

Unless I have been doing something wrong, from my experience it can only retain a single instance of a BO in context at any one time.

Are you sure?

Attached is a simple BSV with 1 process that creates 2 instances of a non-persisted BO and accesses both multiple times.

Maybe it works because it is so simple.

Bob, "Single Instance" means a single copy (unlike a collection - multiple copies, like Customers) not single time to use it.

Ben,

Did you look at my Test.bsv?

"Single Instance" means a single copy (unlike a collection - multiple copies, like Customers)

I agree with that statement and my understanding of the issue is: If multiple instances of a non-persisted BO are created (a collection), AwareIM only keeps 1 instance in context. Any other instance would not be in context and unusable.

If that is an accurate statement of the issue, my test.bsv appears to prove it wrong.

Besides the RegularUser and SystemSettings BOs, the attached BSV has only 1 other BO (nonPers).
nonPers is set as Not persisted and has only 1 Plain Text attribute (nonText)

The BSV has only 1 process (Test2NonPersistedBOs)

Here are the rules for that process, with my comments:

CREATE nonPers WITH nonPers.nonText='Created this BO' // 1 instance created
CREATE nonPers WITH nonPers.nonText='Created that BO' // a second instance created, I now have a collection
DISPLAY MESSAGE ThatnonPers.nonText // I get a popup with: Created that BO. The second instance must be in the context
DISPLAY MESSAGE ThisnonPers.nonText // I get a popup with: Created this BO. The first instance must be in context
ThatnonPers.nonText='Changed that BO' // the second instance is changed
ThisnonPers.nonText='Changed this BO' // the first instance is changed
DISPLAY MESSAGE ThisnonPers.nonText // I get a popup with Changed this BO. The first instance must be in context
DISPLAY MESSAGE ThatnonPers.nonText // I get a popup with Changed that BO. The second instance must be in context
DISPLAY MESSAGE ThisnonPers.nonText + ' ?? ' + ThatnonPers.nonText // I get a popup with Changed this BO ?? Changed that BO both instances must be in context

Doesn't that prove that more than 1 instance of a non-persisted BO can be in the context.

BobK wrote

Ben,

Did you look at my Test.bsv?

"Single Instance" means a single copy (unlike a collection - multiple copies, like Customers)

I agree with that statement and my understanding of the issue is: If multiple instances of a non-persisted BO are created (a collection), AwareIM only keeps 1 instance in context. Any other instance would not be in context and unusable.

If that is an accurate statement of the issue, my test.bsv appears to prove it wrong.

Besides the RegularUser and SystemSettings BOs, the attached BSV has only 1 other BO (nonPers).
nonPers is set as Not persisted and has only 1 Plain Text attribute (nonText)

The BSV has only 1 process (Test2NonPersistedBOs)

Here are the rules for that process, with my comments:

CREATE nonPers WITH nonPers.nonText='Created this BO' // 1 instance created
CREATE nonPers WITH nonPers.nonText='Created that BO' // a second instance created, I now have a collection
DISPLAY MESSAGE ThatnonPers.nonText // I get a popup with: Created that BO. The second instance must be in the context
DISPLAY MESSAGE ThisnonPers.nonText // I get a popup with: Created this BO. The first instance must be in context
ThatnonPers.nonText='Changed that BO' // the second instance is changed
ThisnonPers.nonText='Changed this BO' // the first instance is changed
DISPLAY MESSAGE ThisnonPers.nonText // I get a popup with Changed this BO. The first instance must be in context
DISPLAY MESSAGE ThatnonPers.nonText // I get a popup with Changed that BO. The second instance must be in context
DISPLAY MESSAGE ThisnonPers.nonText + ' ?? ' + ThatnonPers.nonText // I get a popup with Changed this BO ?? Changed that BO both instances must be in context

Doesn't that prove that more than 1 instance of a non-persisted BO can be in the context.

"This" & "That" are actually pointing to two separate objects in the context and are not considered to be a collection.

The real test would be to add 10 customers ( a collection of customers) to a none-persistent object and then try to iterate through them and you will get ONE object back and not 10.

Aware doesn't support this type of memory collection (although it does for it's internal work and collection of "Object references" (not object itself)), because what if a developer loads a million objects into none-persistent object which basically a memory allocation and kills the server.

ACDC wrote

...
Alternatively, if you could address the sort order in the query by way of a tag , I was going to suggest creating a Range object for the purpose of the query. So the query would be run from a process where a single Range Object is created prompting the user for the parameters and then reference the Range object (which is in context) in the query. So every time a report is run a new Range object is created for the purpose of the query parameters - but the sort order breaks this idea

not sure exactly what this means... but for the sort, there's got to be a limited # of sort possibilities. Since you're adding a bunch of new objects to a new [temp] file, have a "SortField" string that gets built dynamically based on the user picking a set of fields to sort by. The query always sorts by "SortField".
User picks "State/Type/Amount" then you dynamically build "FL/A/100", "FL/B/200", "FL/B/201" into that special field.