DataBase/Multiple DataBase Related Events

The following events can be captured:

1. Committing of any cached changes to the database. Called once prior to a Savework, undo, quitwork, setMark, Getwork

2. Pre and post events for the following actions: Savework, Getwork, undo, Redo, drop, flush, quit, refresh. These are only called if the action succeeds, and are there to cope with the changes. The pre events should not make any database changes.

3. Failure event for Savework, flush.

4. Clearing out any local caches.

5. Claim/Release events.

Except for quit, the pre actions are really called post action but with the Database (DB) in the pre action state. The pre action is only called if the action succeeds.

Most of the pre and post actions fall into just two categories:

6. Changes made to the database file itself, but not our view of it (Savework, Flush, Refresh, drop).

7. Changes in our view of the database, but no changes to the database file (Getwork, undo, Redo, quit).

The interested parties are different in the two cases. When changing the database file, the interested parties are 3rd party systems outside of the AVEVA module. When changing our view of the database it is the current session that needs to reflect the changes, for example: update the 3D graphics and explorer.

The events raised reflect this split.

The events are:

• CommitPending - This is called to commit any outstanding change to the database. It is called prior to setmark, undo, redo, Savework, quit, Getwork.

• ClearCache() - This will be called after doing a temporary switch to a different session in a DB, or after doing a Getwork, undo, redo, quit.

  Note:
  ClearCache may be called thousands of times within a single operation. Thus any event handlers must be fast.

• Pre and Post events for local changes. i.e. changes affecting the current view of the data. These will be Getwork, undo, redo.

• Pre and Post events for changes affecting the data on the DB. These will be Savework, refresh, drop, flush, refresh. These will pass the list of changes. For 'global' DBs, if the parent extract is at a different location, the flush event will be raised by the child extract.

  Note:
  In this case the flush could still fail at the parent. Alternatively the daemon needs to raise the flush event.

• Post claim/release events.

• Post failed Getwork/Savework.