Maybe this will be the last Trigger question.

Our triggers are developed to track changes to tables .. blah blah
blah.

In out test we are moving 'source' from one account to another. So

acct name: TEST
tablename: BP (this table has trigger assigned)
qpointer to prod: DSIGBP
Q
PROD
BP

acct name: PROD
tablename: BP (this table has trigger assigned)

at this point we know that the files work well, the triggers work well
and the pointer is working.

So we want to copy from the test table to the prod table.

in test we

COPY BP THISPROGRAM
TODSIGBP

If we look in the production table THISPROGRAM exists (or has been
updated if overwrite)

But the audit information is in the tables for TEST.

In the beginning of our routine we

fld3 = access(3)
fld10 = access(10)
fld11 = access(11)
fld12 = access(12)
fld16 = access(16)
fld23 = access(23)
fld26 = access(26)
fld50 = access(50)

to see what is going on. (these are defined in the manual but
access(5) blows up with illegal accesss .. )

if we debug right after the assignments .. before doing anything

**/FLD3 33=
**/FLD10 THISPROGRAM=
**/FLD11 BP=
**/FLD12 0=
**/FLD16 1=
**/FLD23 1=
**/FLD26 0=

So it looks like the system has already defined the filename from the
qfile but it does not pass this information on anywhere.

How can one know what 'account' is being accessed.

thanks

Hi
I have not tried this but I am suspicious that the infamous "full pathing"
may be involved if you are on D3.
P McMurray
"dtsig" <dtsig (AT) hotmail (DOT) com> wrote

Peter,

Nothing to do with full pathing (really) - just the fact that Q
pointer links are resolved until we arrive at a "real" (DPtr) file,
and the ACCESS functions are then doing the "right" thing and
returning the REAL name of the REAL file!

This guy is going to potentially have other problems if people do
things like STEAL-FILE, create work files on the fly that require
logging and/or even have q pointers to accounts, or USERS, rather than
using the (traditional) "real account".

We faced similar problems when developing our Visage.DRS product - the
issues CAN be solved if you spend enough time wacking your head
against the brick wall! (DRS = Data Replication Service, as an
alternative to D3's "hot backup" that supports replication to multiple
servers, allows for "clean" snapshot backups [VERY useful for people
with ever decreasing backup windows], and also allows replication
servers to be built from "dirty" backups performed when system is in
use (typically for initial establishment). DRS self-heals in the event
of comms failures, maintains multiple journal logs with tuneable
latency, and also works with D3/NT)



On Jan 30, 9:57 am, "Peter McMurray" <excalibu... (AT) bigpond (DOT) com> wrote:

I'm don't have the latest versions of Pick, and I only work with D3 Linux.

It is my belief that with the older versions you won't really know what file
an item was moved into if you have many accounts with the same file name.

I've done some extensive work with file triggers to track changes in
software at the company I work for. The process on the whole works well
until you get the same file name being repeated. You can use the @account
to retrieve the account were the command was issued. Try some more
experimenting on this point.

I thought I saw that the latest version of Pick will allow you to access the
account name where the trigger resides, but I could be mistaken. Maybe
someone else can clarify this point.

Regards,

Dale

"dtsig" <dtsig (AT) hotmail (DOT) com> wrote

Hi Ross
It sounded hairy and it is. Thanks for the explanation. Personally we do
all development on the real files in a real development account with each
user having a logon for it. Then when we release it we again control it all
within a real account and yes we do track change date etc. The Q pointers
are from the application accounts to the real depository umpteen application
accounts with one run-time library.
However all is never perfect, we did have one moron that we found wrote his
own little way (in our time) of releasing stuff to skip the final release
compile. We found it because as part of the final compile we record the
user and the account and time and date. What a mess the idiot made. Better
still he bypassed the proper screen display in one program he wrote and
inserted significant comments as to how his way was much more efficient. He
had replaced a proper parameterised, documented record with a string to
paint the screen that was several hundred bytes long. I fully understand
the expression "shooting is too good for him".
Your backup mirror sounds great.
Peter McMurray
"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

Nope .. reacts the same way.

On Jan 29, 2:57 pm, "Peter McMurray" <excalibu... (AT) bigpond (DOT) com> wrote:

Dale,

thanks for that. I am not sure of the version of D3 we are using. I
have asked the sysadmin and expect a reply soon <sigh>

@account gives the account currently in, not the account that fired
the trigger.

I find it hard to believe that PICK didn't think this part through.
But there it goes. It will require some real HACK but will come up
with something. Thanks for the try.

On Jan 29, 10:06 pm, "Dale" <benedictknows... (AT) silk (DOT) net> wrote:

"dtsig" <dtsig (AT) hotmail (DOT) com> wrote

area.

The trigger is YOU, not a phantom that winks into life to run the trigger
program and then dies. YOU update the file and you run the trigger as an
assembler-level subroutine. If you are in the TEST account and update a
file called BP (after all the qpointer resolution), and I assume you are
opening a file based on the account where the trigger is active and the BP
file, you're going to update the local trace file.

The trigger will have to be smarter, read the file definition from MD and if
it's a q-pointer, or if the filename has a path construction (a,f,) then
open the trace file in THAT account.

If you are using D3 the tcl command is: which (cad

This will display the version of d3 and all the patch levels for the abs,
compiler, etc

My feeling is that you must be fairly new to the D3/Pick world. Relax, get
the manuals out and just start reading. I wouldn't worry about trying to
remember all the information. But as you read thing that you are having
trouble with will be explained. Start reading the BASIC section and then
the TCL and ACCESS/AQL sections. Proc for the most part is a dead issue
unless there is a lot of old software the you need to work with.

Regards,

Dale

"dtsig" <dtsig (AT) hotmail (DOT) com> wrote

Dave:

What happens if you:

:COPY BP THISPROGRAM
toPROD,BP,

?

A "Q" pointer is helpful but not necessary in D3. In fact, a program can
traverse multiple accounts on a D3 system by simply referring to
"AcctName,FileName,", which is "way" cool! There's no such concept within
U2. Coming from U2 to D3, on this, makes one stop and learn more. Coming
from D3 to U2, on this, makes one hit the brick wall and re-engineer.

Call me if you want help.

Bill

"dtsig" <dtsig (AT) hotmail (DOT) com> wrote