On 1/22/2015 4:23 PM, rob wrote:
what you are saying is that the month end (or other batch job) dumps data
into a temporary file to create a particular 'snap shot'. And then you
either have them access that snap shot, or use stored procedures that
access that snap shot via some other reporting tool.
Is that a valid compromise of the explanation between Alan and Buck?
As the ne'er-do-well who opened this can of worms I feel compelled to
reply. The oldest of our reports _behaves_ this way, but it's an
accident, not a deliberate design. When the report runs, it runs
exactly after step 1 and before step 3. The database is in a known,
static, state. The transactions for this month are still in the monthly
file and haven't been moved to the quarterly file, etc. So the report
(again, by accident) happens to only cover the transactions for that
entire month.
If I were to run that program any other day, it would be wrong because
it would report on 'month to date' rather than the whole month. In
essence, without resorting to some CPYF jiggery-pokery, I can't rerun
the report and see the same results. The net effect is that the
'snapshot' is the spooled file :-(
Our more recent efforts put transaction dates (dates!) in the tables,
and by stuffing a 'which month' parameter, we can re-run a report for
any month in the past and come up with the exact same numbers we did
when the thing first ran.
Crystal is parameterised much the same way. Stuff in the month and it
goes off and gets just that month's records. The problem is that the
end of month doesn't happen exactly on the last day of the calendar
month. Depending on how the money is coming in, EOM might wait up to a
week. It's not possible to tell Crystal 'hey, wait up!' - the Crystal
scheduler doesn't have a hook into our business processes. The RPG
programs have that 'hook' implicitly - the programs don't run until our
operator runs them as part of the EOM batch job.
It'd be so cool to fire off a Crystal report from an RPG batch job.
midrange.com
