Hi Helen,

>
> If possible, can you cook up a reproducible test case for the

Tracker? (But I'm still interested to grokk why you're trying to row
two boats at once...)

>
> ./heLen
>

It's not easy to create a reproducible test case - the corruption
seems intermittent, and I have not isolated the particular set of
circumstance in which the corruption occurs. If I can make pin it
down, I will put it on the Tracker.

Why am I running two cursors on the same table at once?

The table represents a sequence of events in a horticultural
production process. Some of the events are critical path (CP)
events, and some are not (NCP). Values on the events need to be
adjusted in response to both preceding and following events.

Examples of CP events are Sowing, Planting, Moving, Potting.

Examples of NCP events are Spraying, Wastage, Sales of Stock. Some of
these events change the quantities on both the preceding and
following CP events.

There are many complications - the amount of space required, whether
a container is used, total area required at each stage, whether the
event has been completed, or is just planned, the time of year (which
affects duration of events), forecast attrition rates at various
stages, 3 plants going into a single pot, and so on.

Here is a simplified sequence:

CP1
NCP1.1
NCP1.2
CP2
NCP2.1
NCP2.2
NCP2.3
CP3
NCP3.1
etc

There are two named cursors:
"CP" selects only the CP events
"ALL_EVENTS" selects all events in the sequence.

Here is the basic program flow:

CP fetches a CP event (initially CP1), and establishes B/F values
which will apply to following events.
ALL_EVENTS then loops from CP1 to CP2, adjusting BF values as it goes
along, updating NCP events with the current BF
values if needed, and stops on the next CP event (CP2).
(In some circumstances events may be deleted or inserted during this
process.)
CP (which is still on CP1) takes the relevant values as updated by
ALL_EVENTS, and updates its current record if there are any changes.
CP then fetches the next record (CP2)
ALL_EVENTS continues its loop through to CP3, CP updates CP2 and
moves to CP3, and so on.
When CP produces a row_count of 0, ALL_EVENTS "knows" that it is in
the final phase.

Maybe this is more information than you wanted...

Roger Vellacott
Passfield Data Systems Ltd