Re: COBOL Compiler for Windows

Robert <no@[EMAIL PROTECTED]
> wrote in message
news:kdtk14pk2oococs6u2ruukcbhmtqmv9ck1@[EMAIL PROTECTED]
> On Fri, 2 May 2008 11:55:22 +1200, "Pete Dashwood"
<dashwood@[EMAIL PROTECTED]
>
> wrote:
> > Suppose, as each transaction occurred in real time it kicked of
> >a sub task (maybe running on a different procesor) that added the
necessary
> >re****t line to the collection right then and there... No need to filter
by
> >date or scan databases, just create the line in real time. (The re****t
> >object could contain a method that filtered its own collection by date
as
> >the lines were sent to the print spool. You can argue that this is also
a
> >batch process, but it isn't within the scope I defined above...)
>
> It's called a Materialized View in Oracle. You don't have to write
anything except
>
> create materialized view foo
>   build immediate refresh on commit enable query rewrite
>   as select customer, count(*) from customers group by customer;
>


I don't know if this process answers the obvious concern that PD's
suggestion doesn't seem to address: that of the posted information
remaining
correct until it's "printed" or otherwise disseminated.  Example: credit
card monthly statements or any A/R listing: customers change their address
between the time the transaction is posted and the time the re****t is
printed.   What's the phrase - you don't commit to a changeable piece of
information or the results of a calculation until you actually have to.

Of course you could have a trigger associated with a customer address
change
which would go in and change the information in the ac***ulating file but
that opens up a whole host of related issues (such as whether the changed
information adds a line or two to the address).  There is a level of
complexity in the on-the-spot real-time approach which, if exceeded, makes
the old-fa****oned batch approach seem very sane and desirable.

PL