Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:
> However, given your above description why does it not
> suffice to regenerate the report whenever the report
> generator connects ? If you want to do so only when the
> table has actually changed you might add a last_modified
> timestamp column with a default of now(), remember that in
> the report generator [...]
Yes, I can add a table that records the last modification date and
report date, and add triggers to all tables to update the modification
date (timestamp) when something changes. But I expected (hoped) that
the database itself could tell me straight away when the last
modification (COMMIT) had been performed.
Background is that the system the database runs on is also used for
other processing. The database is not used frequently. As a result,
the database is usually swapped out which makes the initial connection
rather unresponsive. Database updates are not frequent, hence the idea
to generate the reports on demand, and cache them until the database
changes.
Yes, I know this will not work with any of the discussed approaches
since asking the database for the last modification will also suffer
from the initial unresponsiveness...
-- Johan
