I'm writing a trigger using CALLX to track who changed a record in a
file. I'm using OCONV('','U50BB') in the program to get the person's
port/acct/user, but the OCONV returns garbage characters.

It looks to me like the CALLX is a separate process that isn't the
user's valid port/acct/user. Is this true? If so, how can I get the info
of the person who is changing the record?

This is on D3/NT.

Thanks

Sholom

sh wrote:

Why not just CALL your tracking subroutine from the appropriate
applications that update this file?

Often a file is updated by many processes, of which maybe only a few
are important to track who did the update. Using a trigger means that
all updates by all processes will get logged.

Also, instead of using an old-style user exit, try the @ fuctions.
@user, @account, @pib.

--
Kevin Powick

Thanks, Kevin

Kevin Powick wrote:

Turns out the thing that I'm tracking can mainly be done by procs and
manually at TCL. I'd like to catch it wherever it happens, that's why
CALLX is the best solution.

That was a good idea. I tried it, but it returned null.

Sholom

Could you be a bit more specific about what you're doing.

CALLX should be YOU unless you are doing this thru ODBC or something; then
it's the filesystem that's doing the work and there is no user as such.

Mark Brown

"sh" <shamada (AT) prupipe (DOT) com> wrote

sh wrote:


Did you Flash compile your subroutine? Routines called by CallX must
be compiled with the (O) option.

Also, after compiling and cataloging, you must log off and then back
on. It has to do with some caching of pointers for flashed BASIC code.

--
Kevin Powick

Sholom, not sure what's going on with your system but here are a
couple thoughts:
- I may be wrong about this but as I recall CallX isn't executed in
the same process as the mainline code, so the user you get returned
from a trigger isn't the same as the user that triggered the event.
- I think the user returned from U50bb in a trigger is some varation
of the Windows user because the process is executed as an RPC, or it
may look something like Username$port$
- The @functions may be returning null for the same reason. There is
no underlying process/environment to provide the information being
requested.
- This could be related to Flash/Non-Flash, VME/FSI, or whether your
trigger code is globally catalogued. I won't go into details about
when triggers will or won't work, if it's not in the docs then call RD
Support.

Maybe I just had a major brain fart and just don't remember how that
stuff works, so please take this all with a grain of salt. Triggers
have been notoriously unstable in earlier versions of D3NT and there
have always been problems when trying to process data with triggers
between the VME and FSI. I got tired years ago of trying to get these
particular toys to play nice together so I simply don't use them
unless requested. Same goes for indexes I'm sorry to say. And
because I need to code for cross-platform apps, if I don't use
triggers or indexes in NT that means I don't use them in *nix either.
Shame cuz it's potentially very cool stuff. As with a lot of
features, some of us swear by them and others swear at them. I'm
hoping to check these things out in D3 7.5.

Sorry I can't be more helpful.
T


sh <shamada (AT) prupipe (DOT) com> wrote:

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

I use triggers and indexes all the time. I use soundex a lot, so I usually
have a trigger to convert the plain text to soundex fields which are then
indexed. All our web pages depend heavily on indexing to reduce query times
to minimums. I have a routine that locates dealers within a variable number
of miles from the users zipcode. That uses an index of latitudes/

Sholom, maybe this is really what you want. From D3 Ref:

x correlative

x type ac(v)

provides an audit trail for items that are updated.



type specifies the type of stamp to use, and may be any of the following
choices:



"a" places the name of the user in the specified attribute when the item is
filed.



"d" places the current date in the specified attribute when the item is
filed.



"s" adds the total time (in seconds) the item was in UP into the specified
attribute. The value is cumulative. Each time the item is updated, the
current usage is added to the previous time.



"t" places the current time in the specified attribute when the item is
filed.



"ac" specifies the attribute count into which the stamp is to be placed.



"v" specifies that each time the item is filed, the stamp is to be inserted
as a new value. If "v" is not specified, the current stamp overwrites the
previous entry. The "v" has no effect with the "s" option.



The audit stamp codes may be combined into more complex expressions, such as
"xa1d2s3v". This example will stamp attribute 1 with the user, attribute 2
with the date, and attribute 3 with the time, adding subsequent stamps as
multi-values. When stamp specifications are combined, the system will not
add another stamp if the user and date are the same. For example, if a
stamp already exists for user 'dm' on 09/28/94, and the same user updates
the item on the same date, another stamp will not be added. This does not
apply when specifying stamps separately.


Examples:

1) xa14



This places the user-id in attribute 14.



3) xa3d4t5



This complex expression adds the user-id in attribute 3, the current date in
attribute 4, and the current time in attribute 5.







Mark Brown

Kevin Powick wrote:

I found an alternate way to clear the cache (in fact, I've found that
logging off doesn't always clear the cache - at least not in D3/NT).
After compiling, edit the DICT which has the CALLX, and just do an FI on
it. This seems to force the system to update things.

Thanks, Tony. You and Mark have confirmed my hunch about it not being
the users process.

I think triggers are a great tool when they are the optimum solution,
but I've also had mixed results on getting them to work. They would be a
great place for data integrity checking.

I once used one to debug my application. Somehow, someway we were
getting a null Product record. No matter how much I searched the code, I
couldn't come up with a scenario that would generate a null record. I
placed checking code in the most probable places, but no luck. So I
created a trigger that would check for a null record no matter what
process was doing it. A message would appear advising the user to call
me. When it eventually happened, I interrogated the user to find out the
exact circumstances, and we were able to solve the problem.

Tony Gravagno wrote:

sh wrote:

Good to know. Thanks!

--
Kevin Powick