U2 Gurus,

I am using Unidata 5.2 and am working with using database triggers
to manage a flag attribute on a file.

The trigger looks for a "Y" in attr 45 and converts it to a timedate
stamp. If the field contains anything except a "Y", the trigger nulls
it (therefore setting it up to re-export).

This all works perfectly using a regular unidata login session, but,

When I try to set the Y in the attr and write it out from a vb.net &
uniobjects application, the write blows up with error 39207 (Failed to
read from the slave correctly) and the session object is immediately
terminated.

I have tried using a writev method, a write method, and calling a
subroutine to do the write, but all fail with the subroutine method
returning an error 30107 (Subroutine failed to complete successfuly).

If I remove the update trigger from the file all of the above
methods will write out the record successfully with the "Y" in attr
45.

I am thinking it has something to do with the uniobjects rpc login
not having the correct environment to execute the trigger program?
( I am using the same login to test with the telnet session.)

Maybe having something to do with global cataloging?

Anyone run into this situation or have any ideas?

Any ideas or help would be a godsend, I can't afford to lose any more
hair as it is pretty thin right now.

Thanks,
Steve Shaffer

Steve,

The trigger program must be globally catalogued.

Tom

Tom,

I'm pretty sure that the trigger is globally cataloged and it works
perfectly from inside a normal telnet login.

It is only from a uniobjects/rpc type session to the same username/
password that it blows up.

Steve


On Mar 9, 7:12 am, "tomit" <cord... (AT) sddc (DOT) army.mil> wrote:

Steve,

We're on Unidata.

Uniobjects updates of trigger enabled files work fine on our system.
I'm not aware that our java programmers do anything special.

Are Uniobjects writes working successfully on files without triggers?
If you do a MAKE.MAP.FILE and then edit _MAP_ [trigger program], do
you find it?

Tom

Tom,

Found the problem, it was a common block not initialized which
involved the Manage 2000 ERP environment.

This was causing the trigger program to abort prematurely without
warning or error message.

Thanks so much for your help.

Take Care,
Steve


On Mar 12, 5:50 am, "tomit" <cord... (AT) sddc (DOT) army.mil> wrote: