I have a LOV which is simply selecting the current month. It returns exactly one record. I have a jxls template that can be run on demand (different LOV that is all months), but use the same template file with the limited LOV so I could schedule it to run monthly using the current month. So, two different queries using the same template file.
However, what I think I'm seeing is that the "Schedule Job" is taking a snapshot of the parameter value at the time the job is scheduled. It's not using the LOV query every time the event occurs.
Is this accurate? If so, is there a clever way of working around the need for different template files? I really don't want to have to maintain separate templates if the only change is user selected vs current month.
Make sense? Thanks!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're right in that a job will use the parameter value in effect when the job is scheduled. There is no chance for a user to change this value during job execution. Are you suggesting that this be different?
The multiple template file scenario is not entirely clear. Is this required only with jobs.
Never followed up, but developed a workaround...... here's what I did
one template, one query
in the query the parameter (STARTMONTH) is a LOV of YYYY-MM values, to that list I added a value pair '2050-01','' So, the dropdown looks blank, but the underlying value is '2050-01'
In the query in the jxls template, I added a condition that if STARTMONTH = '2050-01' then use the current month.
Works fine. Query maintenance is a little cumbersome, but worth the effort of not having to maintenance scheduled jobs or multiple queries.
Last edit: JenD 2014-08-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This scenario should be accomodated in the next release (3.1) with the concept of clone reports (one report using the query as defined and maintained in another report), and with the allowing for use of groovy code to provide parameter values, providing the current month string in this example.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a LOV which is simply selecting the current month. It returns exactly one record. I have a jxls template that can be run on demand (different LOV that is all months), but use the same template file with the limited LOV so I could schedule it to run monthly using the current month. So, two different queries using the same template file.
However, what I think I'm seeing is that the "Schedule Job" is taking a snapshot of the parameter value at the time the job is scheduled. It's not using the LOV query every time the event occurs.
Is this accurate? If so, is there a clever way of working around the need for different template files? I really don't want to have to maintain separate templates if the only change is user selected vs current month.
Make sense? Thanks!!
You're right in that a job will use the parameter value in effect when the job is scheduled. There is no chance for a user to change this value during job execution. Are you suggesting that this be different?
The multiple template file scenario is not entirely clear. Is this required only with jobs.
Never followed up, but developed a workaround...... here's what I did
one template, one query
in the query the parameter (STARTMONTH) is a LOV of YYYY-MM values, to that list I added a value pair '2050-01','' So, the dropdown looks blank, but the underlying value is '2050-01'
In the query in the jxls template, I added a condition that if STARTMONTH = '2050-01' then use the current month.
Works fine. Query maintenance is a little cumbersome, but worth the effort of not having to maintenance scheduled jobs or multiple queries.
Last edit: JenD 2014-08-14
The use case may still be useful to implement, from what I could make of it. Created ticket [#132] for this.
Related
Tickets:
#132This scenario should be accomodated in the next release (3.1) with the concept of clone reports (one report using the query as defined and maintained in another report), and with the allowing for use of groovy code to provide parameter values, providing the current month string in this example.