For a year now I've been developing on D3 NT and then porting to a
UniVerse system on Solaris.
I've had to set a few $OPTIONS & have different Btree code but apart
from that its been relatively painless.

Now I want to use triggers.

I have two files, the old stock file which is connected to sales,
purchasing and accounts, and the new stock file which is updated by RF
barcode scanners as people move stuff around the warehouse.
Changes to one stock file need to be reflected in the other.
So in UniVerse I have two triggers, one on each file that updates the
other.
In UniVerse there is a COUNT variable in the trigger subroutine so you
can tell if a trigger has been called by a trigger. This works well &
prevents me causing a 'Cascade' of triggers.

Now I would like to be able to continue development in D3.
I can set up a D3 trigger that can the supply most of the variables
needed for the UniVerse trigger subroutine (Old Record, Old Id, New
Record, New ID, Event).
But how can I tell if a trigger has triggered this trigger?

I thought perhaps keeping a named common for my own COUNT variable
might work but this comment in the D3 manual suggests not.
"Triggers are attached to the file object, and while the code is
shared
among all users, the named commons are not. In other words, the data
stored in a named common is private to the client application."

I suppose then I must write to a file keeping count of triggers
initiated by PID.
This was what I was going to do initally, but I realised that if
trigger locks and the process is logged out the the trigger control
item for a PID would remain & prevent the files from synchonizing.

Any Ideas?

Jeremy Thomson

Duh! The answer is so simple I apologize for the question.
I'll create a routine in the Login Proc to clear the trigger Counts
for that PID.

Jeremy Thomson

On Mar 25, 6:24 pm, panzer... (AT) gmail (DOT) com wrote:
How about adding a field to your stock files: update-source. When one
trigger writes a record it would put a special code in this field
("trigger" or "t" or the name of the other file, or some other equally
insightful string). The "receiving" trigger would watch the update-
source, and not update the other file accordingly.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

On Mar 26, 12:45 pm, panzer... (AT) gmail (DOT) com wrote:
I do some of my best work when I say nothing :-)