Triggers and Qpointers

#11

On Jan 31, 12:35 pm, "Bill H" <y... (AT) notreally (DOT) com> wrote:

Quote:

Dave:

What happens if you:

:COPY BP THISPROGRAM
to

PROD,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" <d... (AT) hotmail (DOT) com> wrote in message

news:1170109828.575560.134740 (AT) a34g2000cwb (DOT) googlegroups.com...

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
TO

DSIGBP

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

Yes .. you can do that but that only helps if you KNOW THE ACCOUNT.
The reason that Qfiles are so nice is there is no need for any
'intelligence' in routines. Meaning they don't have to know where
they are going, it just works.

Triggers SHOULD be smart enough to know where they are going or not
change the FILENAME (in access()).

#12

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

Quote:

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" <d... (AT) hotmail (DOT) com> wrote in message

news:1170171352.627013.209330 (AT) m58g2000cwm (DOT) googlegroups.com...

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:
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" <d... (AT) hotmail (DOT) com> wrote in message

news:1170109828.575560.134740 (AT) a34g2000cwb (DOT) googlegroups.com...

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
TO

DSIGBP

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

not new to it .. back after nice absence. Have gotten the manuals
out. Did you read the problem? Did you understand the problem we
have run into. There is nothing in the manual about this and so I was
looking to see if anyone has gotten past this and how.

#13

On Jan 30, 2:06 pm, "Mark Brown" <mbr... (AT) drexelmgt (DOT) com> wrote:

Quote:

"dtsig" <d... (AT) hotmail (DOT) com> wrote in message

news:1170171352.627013.209330 (AT) m58g2000cwm (DOT) googlegroups.com...> 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.

The version of D3 doesn't really matter. Nothing's really changed in this
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.

Yes .. the trigger IS ME and YES the trigger DOES read the MD item BUT

TEST has table BP. PROD has table BP. Trigger on both. Test has
qpointer PROD.BP. When you write to PROD.BP from Test, ACCESS()
changes the name to BP .. so reading the MD really does no good as it
now is the 'file definition' item from TEST.

This is the catch-22. We believe that we have come up with a
solution, though not one we like we will use it as we have found no
other way to know which environment is actually being processed.

Now, if i am wrong in this i would appreciate hearing it.

Thanks

#14

Triggers are just PickBasic subroutines and no smarter than any other piece
of code you write.

Access(11?) returns filename as it is on the file. Once you've opened the
file, the system doesn't save the "name", only the address which points to a
file control block. That file control block does not contain the name of
the qpointer you pointed at the file, but the file itself, which it gladly
returns to Access function.

)

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

Quote:

Triggers SHOULD be smart enough to know where they are going or not
change the FILENAME (in access()).

#15

On Feb 5, 12:38 pm, "Mark Brown" <mbr... (AT) drexelmgt (DOT) com> wrote:

Quote:

Triggers are just PickBasic subroutines and no smarter than any other piece
of code you write.

Access(11?) returns filename as it is on the file. Once you've opened the
file, the system doesn't save the "name", only the address which points to a
file control block. That file control block does not contain the name of
the qpointer you pointed at the file, but the file itself, which it gladly
returns to Access function.

)

"dtsig" <d... (AT) hotmail (DOT) com> wrote in message

news:1170688518.208524.171520 (AT) v45g2000cwv (DOT) googlegroups.com...

Triggers SHOULD be smart enough to know where they are going or not
change the FILENAME (in access()).

You are of course right .. it is no smarter than any other program
PICK program and there in lies the problem. There is no reason that a
trigger would not know the name of the file opened, the account the
file that is being written to etc. ACCESS is modified for triggers to
contain different information than it contains when in a LIST
statement.

Of course writing work-arounds for the limitations does create great
income <G>

Just trying to get the most for the client with the tools they have
chosen.

thanks for the help

#16

As a simple follow up ..

We have found that the simplest method of knowing where we are going
vs where we are is to add a record to the dictionary of every table we
are going to 'trigger'.

We have created a record (in our case) AUDIT_SOURCE_OWNER with field 1
containing the ACCOUNT owning the table we are going to.

This some some other fudging (creating qpointers to the 'audit tables'
etc) allow us to maintain 1 code piece which works in an single
account or multiple accounts.

Seemed like the easiet way to do this.

Thanks to everyone who offered assistance and advice.

DTsig

On Jan 29, 2:30 pm, "dtsig" <d... (AT) hotmail (DOT) com> wrote:

Quote:

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
TO

DSIGBP

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

#17

Ah...dtsig's seen the light and started considerate posting (my name for
top) Thank you

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

Quote:

As a simple follow up ..

We have found that the simplest method of knowing where we are going
vs where we are is to add a record to the dictionary of every table we
are going to 'trigger'.

We have created a record (in our case) AUDIT_SOURCE_OWNER with field 1
containing the ACCOUNT owning the table we are going to.

This some some other fudging (creating qpointers to the 'audit tables'
etc) allow us to maintain 1 code piece which works in an single
account or multiple accounts.

Seemed like the easiet way to do this.

Thanks to everyone who offered assistance and advice.

DTsig

On Jan 29, 2:30 pm, "dtsig" <d... (AT) hotmail (DOT) com> wrote:
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
TO

DSIGBP

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

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Triggers and Qpointers

comp.databases.pick comp.databases.pick

Re: Triggers and Qpointers - 02-05-2007 , 09:15 AM

Re: Triggers and Qpointers - 02-05-2007 , 09:19 AM

Re: Triggers and Qpointers - 02-05-2007 , 09:44 AM

Re: Triggers and Qpointers - 02-05-2007 , 02:38 PM

Re: Triggers and Qpointers - 02-06-2007 , 08:40 AM

Re: Triggers and Qpointers - 02-07-2007 , 02:32 PM

Re: Triggers and Qpointers - 02-07-2007 , 04:28 PM