Karsten Hilbert <Karsten.Hilbert@xxxxxxx> 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
