Mostly, that is.
To make the midtier report correctly, you have to make an AL as follows:
Associated Form: ReportSelection
Execution Options: order 5. Field: ReportList. Row Choice
RunIf Qual: ((('Start Command' != $NULL$) AND ('Start Command' != ""))
AND ('Report Type' = "AR System")) AND ($CLIENT-TYPE$ = 9)
Set Fields: DataSource Server: Form: ReportCreator
Qual: $Report Name$ = 'Report Name'
Query = $Qualification Ids$
Set Fields Datasource: Current Screen
Query = $PROCESS$ @@:Application-Parse-Qual "$Form Name$" $Query$
Set Fields Datasource: Current Screen
Query = $PROCESS$ @@:Application-Format-Qual "$Form Name$" $Query$
Finally, you have to set Override Query In Report to YES. I know that
is crazy. There is a field called 'Override Query Int Value' that if
set to 1 (somehow) allows the midtier to use the query that is in the
'Query' field. So even though we are pulling in the query FROM the
report, we still need to override it. This is not necessary for the
WUT, but you'll need to make an AL for WUT to get that to work
(basically exactly as Chuck Baldi wrote).
For WUT to work correctly, make an AL like this:
Associated Form: ReportSelection
Execution Options: order 5. Field: ReportList. Row Choice
((('Start Command' != $NULL$) AND ('Start Command' != "")) AND ('Report
Type' = "AR System")) AND ($CLIENT-TYPE$ != 9)
Set Fields: DataSource Server: Form: ReportCreator
Qual: $Report Name$ = 'Report Name'
Query = $Qualification Ids$
The WUT seems to ignore the 'Override Query Int Value' and always looks
at the 'Query' field, for better or worse.
If you really do want to override the query, the easiest thing to do is
unhide the 'Query' field and just erase the contents before clicking Run.
I hope this helps someone, but I may be the only person using the native
reporting tools (or at least the ReportSelection form).
Brien
On 4/22/2010 1:34 PM, Brien Dieterle wrote:
From the midtier, using the ReportSelection form works fine, with a
caveat. If a report (created with the ReportCreator form) has a query
that contains arithmetic such as 'date_field' > $\DATE$ - 60 * 60 * 24
* 10, the report returns nothing (no error message, just blank).
However, queries without calculations such as 'date_field' > $\DATE$
or just 'date_field' > (some_number) work fine. Does anyone know of
a work around for this? I've submitted an issue as well, but there
appear to be multiple open issues with qualifications and the
ReportSelection form.
The strangest part is the WUT doesn't use the qualification at all,
but the midtier does (with the aforementioned caveat). As Chuck Baldi
discovered last year, the "Run" button AL opens a window report with a
qualification of EXTERNAL($query$). However, the $query$ field is
blank and has no workflow associated with it (it is always blank!).
And yet, somehow (magic?) the midtier can run the report with the
qualification, presumably executing the same AL. If I implement the
workaround Chuck created (set the $query$ field), the WUT runs fine
with the qualification in effect, even with date calculations!
Progress? No: this same work-around BREAKS the midtier even more for
queries that use keywords such as $DATE$, etc, because those are
stored as the internal representation such as $\-4$, which the midtier
doesn't understand. I am trying to fix it with the
application-parse-query process commands but having difficulty since
those only run as filters not as ALs.
Thanks for any advice!
Brien
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
