[U2] Very Weird Trigger Behavior
Hi, all. I'm new to this forum, but have been programming multivalue database apps for years. I ran across something here that really has me puzzled. I wonder if anyone has seen something like this and might be able to shed a bit of light as to what's happening. I'm running Unidata 6.0 on hpux. I have a trigger set up to run before deletions take place on a file called CODE_DEFS. The file just contains code numbers (ID) and their meaning/description. There's another file, TRADES, that contains a field, TRADE_CODE, that should have a many-to-one relationship with IDs in CODE_DEFS. That is, the content of TRADE_CODE should match a record ID in CODE_DEFS. Before a record is deleted from CODE_DEFS, I want to ensure its ID does not appear in any record in TRADES. That's where the trigger comes in. The trigger is passed the ID of the record to be deleted. This is done via parameter variable CODE_DEF_ID. The trigger program, CHECK_TRADES, has the following logic: --- . . . CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' EXECUTE CMD IF SYSTEM(11) THEN * there's a select list, so the code is still in use in TRADES. * Return 0 in EXECUTE_STATUS to disallow the deletion. EXECUTE_STATUS=0 END . . . --- The problem is when I try to delete a record from CODE_DEFS, using a TCL DELETE command, I get the following error message. '' is not a record in TRADES Of course, there are two problems with the error message. Not only has it lost the ID of the record to be deleted, it has also lost the name of the file. Notice that it is looking in the TRADES file instead of CODE_DEFS. I believe what's happening is when it EXECUTEs the CMD, the internal variables for ID and filename are being reset. To support this hunch, I changed the trigger routine so that CMD=DATE, causing it to execute the TCL DATE command. Here's the error message from that: '' is not a record in CODE_DEFS And if I make CMD=COUNT CUST, which makes the trigger deal with a completely unrelated file, I get this error message: '' is not a record in @7X% So, it appears that any EXECUTE is going to lose the ID, and if CMD deals with any file, the filename is reset also. I really need to have it perform the intended check before deletion. Any ideas? -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31450305.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Instead of using a SELECT statement build an index on TRADE_CODE in the TRADES file. Use the unibasic index command SETINDEX to tell you if a specified value has any entries in the TRADES file. I don't think a trigger subroutine is an appropriate place for a SELECT statement. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 11:03 AM To: u2-users@listserver.u2ug.org Subject: [U2] Very Weird Trigger Behavior Hi, all. I'm new to this forum, but have been programming multivalue database apps for years. I ran across something here that really has me puzzled. I wonder if anyone has seen something like this and might be able to shed a bit of light as to what's happening. I'm running Unidata 6.0 on hpux. I have a trigger set up to run before deletions take place on a file called CODE_DEFS. The file just contains code numbers (ID) and their meaning/description. There's another file, TRADES, that contains a field, TRADE_CODE, that should have a many-to-one relationship with IDs in CODE_DEFS. That is, the content of TRADE_CODE should match a record ID in CODE_DEFS. Before a record is deleted from CODE_DEFS, I want to ensure its ID does not appear in any record in TRADES. That's where the trigger comes in. The trigger is passed the ID of the record to be deleted. This is done via parameter variable CODE_DEF_ID. The trigger program, CHECK_TRADES, has the following logic: --- . . . CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' EXECUTE CMD IF SYSTEM(11) THEN * there's a select list, so the code is still in use in TRADES. * Return 0 in EXECUTE_STATUS to disallow the deletion. EXECUTE_STATUS=0 END . . . --- The problem is when I try to delete a record from CODE_DEFS, using a TCL DELETE command, I get the following error message. '' is not a record in TRADES Of course, there are two problems with the error message. Not only has it lost the ID of the record to be deleted, it has also lost the name of the file. Notice that it is looking in the TRADES file instead of CODE_DEFS. I believe what's happening is when it EXECUTEs the CMD, the internal variables for ID and filename are being reset. To support this hunch, I changed the trigger routine so that CMD=DATE, causing it to execute the TCL DATE command. Here's the error message from that: '' is not a record in CODE_DEFS And if I make CMD=COUNT CUST, which makes the trigger deal with a completely unrelated file, I get this error message: '' is not a record in @7X% So, it appears that any EXECUTE is going to lose the ID, and if CMD deals with any file, the filename is reset also. I really need to have it perform the intended check before deletion. Any ideas? -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31450305.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users html body Dave Davis Team Lead, Ramp;D P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif] 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. /body /html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Just a thought would be to change your select to use the non-default active select list. For example, instead of: CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' try CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:' TO 2' If you are running in PICK flavor, change the SELECT to select to force it to run in native UniData flavor. I am not sure how this will work with the SYSTEM(11) command, but even if that does not work, there are other ways to test if anything was returned. Note that if you DO need to loop through this, you may need to change code to read from active select 2 (not the default). You might also want to do a CLEARSELECT (or CLEARSELECT 2). John Israel Senior Programmer/Analyst Dayton Superior Corporation 1125 Byers Road Miamisburg, OH 45342 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 11:03 AM To: u2-users@listserver.u2ug.org Subject: [U2] Very Weird Trigger Behavior Hi, all. I'm new to this forum, but have been programming multivalue database apps for years. I ran across something here that really has me puzzled. I wonder if anyone has seen something like this and might be able to shed a bit of light as to what's happening. I'm running Unidata 6.0 on hpux. I have a trigger set up to run before deletions take place on a file called CODE_DEFS. The file just contains code numbers (ID) and their meaning/description. There's another file, TRADES, that contains a field, TRADE_CODE, that should have a many-to-one relationship with IDs in CODE_DEFS. That is, the content of TRADE_CODE should match a record ID in CODE_DEFS. Before a record is deleted from CODE_DEFS, I want to ensure its ID does not appear in any record in TRADES. That's where the trigger comes in. The trigger is passed the ID of the record to be deleted. This is done via parameter variable CODE_DEF_ID. The trigger program, CHECK_TRADES, has the following logic: --- . . . CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' EXECUTE CMD IF SYSTEM(11) THEN * there's a select list, so the code is still in use in TRADES. * Return 0 in EXECUTE_STATUS to disallow the deletion. EXECUTE_STATUS=0 END . . . --- The problem is when I try to delete a record from CODE_DEFS, using a TCL DELETE command, I get the following error message. '' is not a record in TRADES Of course, there are two problems with the error message. Not only has it lost the ID of the record to be deleted, it has also lost the name of the file. Notice that it is looking in the TRADES file instead of CODE_DEFS. I believe what's happening is when it EXECUTEs the CMD, the internal variables for ID and filename are being reset. To support this hunch, I changed the trigger routine so that CMD=DATE, causing it to execute the TCL DATE command. Here's the error message from that: '' is not a record in CODE_DEFS And if I make CMD=COUNT CUST, which makes the trigger deal with a completely unrelated file, I get this error message: '' is not a record in @7X% So, it appears that any EXECUTE is going to lose the ID, and if CMD deals with any file, the filename is reset also. I really need to have it perform the intended check before deletion. Any ideas? -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31450305.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
I would change the SELECT to an XLATE command. David A. Green (480) 813-1725 DAG Consulting -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 8:03 AM To: u2-users@listserver.u2ug.org Subject: [U2] Very Weird Trigger Behavior Hi, all. I'm new to this forum, but have been programming multivalue database apps for years. I ran across something here that really has me puzzled. I wonder if anyone has seen something like this and might be able to shed a bit of light as to what's happening. I'm running Unidata 6.0 on hpux. I have a trigger set up to run before deletions take place on a file called CODE_DEFS. The file just contains code numbers (ID) and their meaning/description. There's another file, TRADES, that contains a field, TRADE_CODE, that should have a many-to-one relationship with IDs in CODE_DEFS. That is, the content of TRADE_CODE should match a record ID in CODE_DEFS. Before a record is deleted from CODE_DEFS, I want to ensure its ID does not appear in any record in TRADES. That's where the trigger comes in. The trigger is passed the ID of the record to be deleted. This is done via parameter variable CODE_DEF_ID. The trigger program, CHECK_TRADES, has the following logic: --- . . . CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' EXECUTE CMD IF SYSTEM(11) THEN * there's a select list, so the code is still in use in TRADES. * Return 0 in EXECUTE_STATUS to disallow the deletion. EXECUTE_STATUS=0 END . . . --- The problem is when I try to delete a record from CODE_DEFS, using a TCL DELETE command, I get the following error message. '' is not a record in TRADES Of course, there are two problems with the error message. Not only has it lost the ID of the record to be deleted, it has also lost the name of the file. Notice that it is looking in the TRADES file instead of CODE_DEFS. I believe what's happening is when it EXECUTEs the CMD, the internal variables for ID and filename are being reset. To support this hunch, I changed the trigger routine so that CMD=DATE, causing it to execute the TCL DATE command. Here's the error message from that: '' is not a record in CODE_DEFS And if I make CMD=COUNT CUST, which makes the trigger deal with a completely unrelated file, I get this error message: '' is not a record in @7X% So, it appears that any EXECUTE is going to lose the ID, and if CMD deals with any file, the filename is reset also. I really need to have it perform the intended check before deletion. Any ideas? -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31450305.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
I think this was a check to prevent deletion of a CODE_DEFS record if in use in the TRADES file, so XLATE wouldn't help. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David A. Green Sent: Thursday, April 21, 2011 11:27 AM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior I would change the SELECT to an XLATE command. David A. Green (480) 813-1725 DAG Consulting -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 8:03 AM To: u2-users@listserver.u2ug.org Subject: [U2] Very Weird Trigger Behavior Hi, all. I'm new to this forum, but have been programming multivalue database apps for years. I ran across something here that really has me puzzled. I wonder if anyone has seen something like this and might be able to shed a bit of light as to what's happening. I'm running Unidata 6.0 on hpux. I have a trigger set up to run before deletions take place on a file called CODE_DEFS. The file just contains code numbers (ID) and their meaning/description. There's another file, TRADES, that contains a field, TRADE_CODE, that should have a many-to-one relationship with IDs in CODE_DEFS. That is, the content of TRADE_CODE should match a record ID in CODE_DEFS. Before a record is deleted from CODE_DEFS, I want to ensure its ID does not appear in any record in TRADES. That's where the trigger comes in. The trigger is passed the ID of the record to be deleted. This is done via parameter variable CODE_DEF_ID. The trigger program, CHECK_TRADES, has the following logic: --- . . . CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' EXECUTE CMD IF SYSTEM(11) THEN * there's a select list, so the code is still in use in TRADES. * Return 0 in EXECUTE_STATUS to disallow the deletion. EXECUTE_STATUS=0 END . . . --- The problem is when I try to delete a record from CODE_DEFS, using a TCL DELETE command, I get the following error message. '' is not a record in TRADES Of course, there are two problems with the error message. Not only has it lost the ID of the record to be deleted, it has also lost the name of the file. Notice that it is looking in the TRADES file instead of CODE_DEFS. I believe what's happening is when it EXECUTEs the CMD, the internal variables for ID and filename are being reset. To support this hunch, I changed the trigger routine so that CMD=DATE, causing it to execute the TCL DATE command. Here's the error message from that: '' is not a record in CODE_DEFS And if I make CMD=COUNT CUST, which makes the trigger deal with a completely unrelated file, I get this error message: '' is not a record in @7X% So, it appears that any EXECUTE is going to lose the ID, and if CMD deals with any file, the filename is reset also. I really need to have it perform the intended check before deletion. Any ideas? -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31450305.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users html body Dave Davis Team Lead, Ramp;D P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif] 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. /body /html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] AUTO: Milton Keynes office closed for English public holidays (returning 26/04/2011)
I am out of the office until 26/04/2011. The Milton Keynes office is closed on Friday and Monday for Easter public holidays. For 8.5 migration and concierge queries issues requiring attention before Tuesday, please email lha...@us.ibm.com and pkl...@us.ibm.com. For urgent problems please raise through your normal support channels. Note: This is an automated response to your message [U2] Very Weird Trigger Behavior sent on 21/4/11 16:03:18. This is the only notification you will receive while this person is away. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
You're right of course that would only work if you have access to the key. If you don't then creating an Index is the best way to go. David A. Green (480) 813-1725 DAG Consulting -Original Message- From: Dave Davis [mailto:dda...@harriscomputer.com] Sent: Thursday, April 21, 2011 8:36 AM To: dgr...@dagconsulting.com; U2 Users List Subject: RE: [U2] Very Weird Trigger Behavior I think this was a check to prevent deletion of a CODE_DEFS record if in use in the TRADES file, so XLATE wouldn't help. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David A. Green Sent: Thursday, April 21, 2011 11:27 AM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior I would change the SELECT to an XLATE command. David A. Green (480) 813-1725 DAG Consulting -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 8:03 AM To: u2-users@listserver.u2ug.org Subject: [U2] Very Weird Trigger Behavior Hi, all. I'm new to this forum, but have been programming multivalue database apps for years. I ran across something here that really has me puzzled. I wonder if anyone has seen something like this and might be able to shed a bit of light as to what's happening. I'm running Unidata 6.0 on hpux. I have a trigger set up to run before deletions take place on a file called CODE_DEFS. The file just contains code numbers (ID) and their meaning/description. There's another file, TRADES, that contains a field, TRADE_CODE, that should have a many-to-one relationship with IDs in CODE_DEFS. That is, the content of TRADE_CODE should match a record ID in CODE_DEFS. Before a record is deleted from CODE_DEFS, I want to ensure its ID does not appear in any record in TRADES. That's where the trigger comes in. The trigger is passed the ID of the record to be deleted. This is done via parameter variable CODE_DEF_ID. The trigger program, CHECK_TRADES, has the following logic: --- . . . CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' EXECUTE CMD IF SYSTEM(11) THEN * there's a select list, so the code is still in use in TRADES. * Return 0 in EXECUTE_STATUS to disallow the deletion. EXECUTE_STATUS=0 END . . . --- The problem is when I try to delete a record from CODE_DEFS, using a TCL DELETE command, I get the following error message. '' is not a record in TRADES Of course, there are two problems with the error message. Not only has it lost the ID of the record to be deleted, it has also lost the name of the file. Notice that it is looking in the TRADES file instead of CODE_DEFS. I believe what's happening is when it EXECUTEs the CMD, the internal variables for ID and filename are being reset. To support this hunch, I changed the trigger routine so that CMD=DATE, causing it to execute the TCL DATE command. Here's the error message from that: '' is not a record in CODE_DEFS And if I make CMD=COUNT CUST, which makes the trigger deal with a completely unrelated file, I get this error message: '' is not a record in @7X% So, it appears that any EXECUTE is going to lose the ID, and if CMD deals with any file, the filename is reset also. I really need to have it perform the intended check before deletion. Any ideas? -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31450305.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users html body Dave Davis Team Lead, Ramp;D P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif] 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. /body /html ___ U2-Users mailing list U2-Users@listserver.u2ug.org
Re: [U2] AUTO: Milton Keynes office closed for English public holidays (returning 26/04/2011)
Sorry about this - I will try to work out a way to block these. Regards - Chris Thornton From: Chris Thornton1/UK/IBM@IBMGB To: U2 Users List u2-users@listserver.u2ug.org Date: 21/04/2011 16:40 Subject:[U2] AUTO: Milton Keynes office closed for English public holidays(returning 26/04/2011) Sent by:u2-users-boun...@listserver.u2ug.org I am out of the office until 26/04/2011. The Milton Keynes office is closed on Friday and Monday for Easter public holidays. For 8.5 migration and concierge queries issues requiring attention before Tuesday, please email lha...@us.ibm.com and pkl...@us.ibm.com. For urgent problems please raise through your normal support channels. Note: This is an automated response to your message [U2] Very Weird Trigger Behavior sent on 21/4/11 16:03:18. This is the only notification you will receive while this person is away. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] AUTO: Milton Keynes office closed for English public holidays (returning 26/04/2011)
Do I forsee any upcoming t-shirts? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Chris Thornton1 Sent: Thursday, April 21, 2011 12:19 PM To: U2 Users List Subject: Re: [U2] AUTO: Milton Keynes office closed for English public holidays (returning 26/04/2011) Sorry about this - I will try to work out a way to block these. Regards - Chris Thornton ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] AUTO: Milton Keynes office closed for English public holidays (returning 26/04/2011)
From: George Gallen ggal...@wyanokegroup.com Do I forsee any upcoming t-shirts? Royal Wedding holiday is not till next Thursday; I've so far resisted that particular temptation. Regards - Chris Thornton Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
I would agree -- if there is an active select list, then you would get some seriously unexpected behavior doing another select unless you 'pushed' that new select to a different 'List ID' than the default '0' list -- just ensure it's a ListID that you KNOW would never be used anywhere else. Back to the 'ideal' - the index is the 'best answer' as it will be faster AND it would avoid the entire 'select' in the first place. The downside of the index may be the in the use of this code -- if every records ends up with a status of DONE, you probably would hate to index that 'status' field since it would be a VERY large index for the DONE set of keys... DW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R. Sent: Thursday, April 21, 2011 10:10 AM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior Just a thought would be to change your select to use the non-default active select list. For example, instead of: CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' try CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:' TO 2' If you are running in PICK flavor, change the SELECT to select to force it to run in native UniData flavor. I am not sure how this will work with the SYSTEM(11) command, but even if that does not work, there are other ways to test if anything was returned. Note that if you DO need to loop through this, you may need to change code to read from active select 2 (not the default). You might also want to do a CLEARSELECT (or CLEARSELECT 2). John Israel Senior Programmer/Analyst Dayton Superior Corporation 1125 Byers Road Miamisburg, OH 45342 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 11:03 AM To: u2-users@listserver.u2ug.org Subject: [U2] Very Weird Trigger Behavior Hi, all. I'm new to this forum, but have been programming multivalue database apps for years. I ran across something here that really has me puzzled. I wonder if anyone has seen something like this and might be able to shed a bit of light as to what's happening. I'm running Unidata 6.0 on hpux. I have a trigger set up to run before deletions take place on a file called CODE_DEFS. The file just contains code numbers (ID) and their meaning/description. There's another file, TRADES, that contains a field, TRADE_CODE, that should have a many-to-one relationship with IDs in CODE_DEFS. That is, the content of TRADE_CODE should match a record ID in CODE_DEFS. Before a record is deleted from CODE_DEFS, I want to ensure its ID does not appear in any record in TRADES. That's where the trigger comes in. The trigger is passed the ID of the record to be deleted. This is done via parameter variable CODE_DEF_ID. The trigger program, CHECK_TRADES, has the following logic: --- . . . CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' EXECUTE CMD IF SYSTEM(11) THEN * there's a select list, so the code is still in use in TRADES. * Return 0 in EXECUTE_STATUS to disallow the deletion. EXECUTE_STATUS=0 END . . . --- The problem is when I try to delete a record from CODE_DEFS, using a TCL DELETE command, I get the following error message. '' is not a record in TRADES Of course, there are two problems with the error message. Not only has it lost the ID of the record to be deleted, it has also lost the name of the file. Notice that it is looking in the TRADES file instead of CODE_DEFS. I believe what's happening is when it EXECUTEs the CMD, the internal variables for ID and filename are being reset. To support this hunch, I changed the trigger routine so that CMD=DATE, causing it to execute the TCL DATE command. Here's the error message from that: '' is not a record in CODE_DEFS And if I make CMD=COUNT CUST, which makes the trigger deal with a completely unrelated file, I get this error message: '' is not a record in @7X% So, it appears that any EXECUTE is going to lose the ID, and if CMD deals with any file, the filename is reset also. I really need to have it perform the intended check before deletion. Any ideas? -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31450305.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Not knowing the size of the original files, as long as they are not too big, adding an index just to get a trigger to work might be serious overkill. You would need to make that call as only you know the size and performance hits involved in this. Just my 2 cents worth (1 cent in this economy). John Israel Senior Programmer/Analyst Dayton Superior Corporation 1125 Byers Road Miamisburg, OH 45342 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Wolverton Sent: Thursday, April 21, 2011 12:45 PM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior I would agree -- if there is an active select list, then you would get some seriously unexpected behavior doing another select unless you 'pushed' that new select to a different 'List ID' than the default '0' list -- just ensure it's a ListID that you KNOW would never be used anywhere else. Back to the 'ideal' - the index is the 'best answer' as it will be faster AND it would avoid the entire 'select' in the first place. The downside of the index may be the in the use of this code -- if every records ends up with a status of DONE, you probably would hate to index that 'status' field since it would be a VERY large index for the DONE set of keys... DW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R. Sent: Thursday, April 21, 2011 10:10 AM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior Just a thought would be to change your select to use the non-default active select list. For example, instead of: CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' try CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:' TO 2' If you are running in PICK flavor, change the SELECT to select to force it to run in native UniData flavor. I am not sure how this will work with the SYSTEM(11) command, but even if that does not work, there are other ways to test if anything was returned. Note that if you DO need to loop through this, you may need to change code to read from active select 2 (not the default). You might also want to do a CLEARSELECT (or CLEARSELECT 2). John Israel Senior Programmer/Analyst Dayton Superior Corporation 1125 Byers Road Miamisburg, OH 45342 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 11:03 AM To: u2-users@listserver.u2ug.org Subject: [U2] Very Weird Trigger Behavior Hi, all. I'm new to this forum, but have been programming multivalue database apps for years. I ran across something here that really has me puzzled. I wonder if anyone has seen something like this and might be able to shed a bit of light as to what's happening. I'm running Unidata 6.0 on hpux. I have a trigger set up to run before deletions take place on a file called CODE_DEFS. The file just contains code numbers (ID) and their meaning/description. There's another file, TRADES, that contains a field, TRADE_CODE, that should have a many-to-one relationship with IDs in CODE_DEFS. That is, the content of TRADE_CODE should match a record ID in CODE_DEFS. Before a record is deleted from CODE_DEFS, I want to ensure its ID does not appear in any record in TRADES. That's where the trigger comes in. The trigger is passed the ID of the record to be deleted. This is done via parameter variable CODE_DEF_ID. The trigger program, CHECK_TRADES, has the following logic: --- . . . CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' EXECUTE CMD IF SYSTEM(11) THEN * there's a select list, so the code is still in use in TRADES. * Return 0 in EXECUTE_STATUS to disallow the deletion. EXECUTE_STATUS=0 END . . . --- The problem is when I try to delete a record from CODE_DEFS, using a TCL DELETE command, I get the following error message. '' is not a record in TRADES Of course, there are two problems with the error message. Not only has it lost the ID of the record to be deleted, it has also lost the name of the file. Notice that it is looking in the TRADES file instead of CODE_DEFS. I believe what's happening is when it EXECUTEs the CMD, the internal variables for ID and filename are being reset. To support this hunch, I changed the trigger routine so that CMD=DATE, causing it to execute the TCL DATE command. Here's the error message from that: '' is not a record in CODE_DEFS And if I make CMD=COUNT CUST, which makes the trigger deal with a completely unrelated file, I get this error message: '' is not a record in @7X% So, it appears that any EXECUTE is going to lose the ID, and if CMD deals with any file, the filename is reset also. I really need to have it perform the intended
Re: [U2] Very Weird Trigger Behavior
On 4/21/2011 11:03 AM, jonathanm wrote: Hi, all. I'm new to this forum, but have been programming multivalue database snip I really need to have it perform the intended check before deletion. Any ideas? Your execute of the SELECT will potentially result in an active select list that doesn't appear to be intentionally used. Since you don't want the ids, you just want to know if there are any, I'd do something like: CMD - 'COUNT TRADES WITH TRADE_CODE = ': CODE_DEF_ID: '' EXECUTE CMD CAPTURING CMD.CAP RETURNING CNT.SELECTED IF (CNT.SELECTED GT 0) THEN EXECUTE_STATUS = 0 END ELSE EXECUTE_STATUS = END I also don't know what you're doing with EXECUTE_STATUS, but if it's not set by the caller, it needs to be set here, otherwise its value is undetermined, (and in most cases will be set to null). Regards. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Then there is the possibility of adding another trigger to the update of the TRADES file that builds a CODES.XRF cross reference file. You avoid the large nothing index, gives you a straight READ, plus it's an easy rebuild program. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R. Sent: Thursday, April 21, 2011 9:52 AM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior Not knowing the size of the original files, as long as they are not too big, adding an index just to get a trigger to work might be serious overkill. You would need to make that call as only you know the size and performance hits involved in this. Just my 2 cents worth (1 cent in this economy). John Israel Senior Programmer/Analyst Dayton Superior Corporation 1125 Byers Road Miamisburg, OH 45342 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Wolverton Sent: Thursday, April 21, 2011 12:45 PM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior I would agree -- if there is an active select list, then you would get some seriously unexpected behavior doing another select unless you 'pushed' that new select to a different 'List ID' than the default '0' list -- just ensure it's a ListID that you KNOW would never be used anywhere else. Back to the 'ideal' - the index is the 'best answer' as it will be faster AND it would avoid the entire 'select' in the first place. The downside of the index may be the in the use of this code -- if every records ends up with a status of DONE, you probably would hate to index that 'status' field since it would be a VERY large index for the DONE set of keys... DW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R. Sent: Thursday, April 21, 2011 10:10 AM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior Just a thought would be to change your select to use the non-default active select list. For example, instead of: CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' try CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:' TO 2' If you are running in PICK flavor, change the SELECT to select to force it to run in native UniData flavor. I am not sure how this will work with the SYSTEM(11) command, but even if that does not work, there are other ways to test if anything was returned. Note that if you DO need to loop through this, you may need to change code to read from active select 2 (not the default). You might also want to do a CLEARSELECT (or CLEARSELECT 2). John Israel Senior Programmer/Analyst Dayton Superior Corporation 1125 Byers Road Miamisburg, OH 45342 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 11:03 AM To: u2-users@listserver.u2ug.org Subject: [U2] Very Weird Trigger Behavior Hi, all. I'm new to this forum, but have been programming multivalue database apps for years. I ran across something here that really has me puzzled. I wonder if anyone has seen something like this and might be able to shed a bit of light as to what's happening. I'm running Unidata 6.0 on hpux. I have a trigger set up to run before deletions take place on a file called CODE_DEFS. The file just contains code numbers (ID) and their meaning/description. There's another file, TRADES, that contains a field, TRADE_CODE, that should have a many-to-one relationship with IDs in CODE_DEFS. That is, the content of TRADE_CODE should match a record ID in CODE_DEFS. Before a record is deleted from CODE_DEFS, I want to ensure its ID does not appear in any record in TRADES. That's where the trigger comes in. The trigger is passed the ID of the record to be deleted. This is done via parameter variable CODE_DEF_ID. The trigger program, CHECK_TRADES, has the following logic: --- . . . CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' EXECUTE CMD IF SYSTEM(11) THEN * there's a select list, so the code is still in use in TRADES. * Return 0 in EXECUTE_STATUS to disallow the deletion. EXECUTE_STATUS=0 END . . . --- The problem is when I try to delete a record from CODE_DEFS, using a TCL DELETE command, I get the following error message. '' is not a record in TRADES Of course, there are two problems with the error message. Not only has it lost the ID of the record to be deleted, it has also lost the name of the file. Notice that it is looking in the TRADES file instead of CODE_DEFS. I believe what's happening is when it EXECUTEs the CMD, the internal variables for ID and filename are being reset. To support
Re: [U2] Very Weird Trigger Behavior
Come to think of it, you could even use the CODE_DEFS file for its own cross reference. Since it's such a simple file with probably only a single attribute, use the second attribute as a MV field of TRADES ID values. But then you have possible lock issues that might not make this a smart idea. Like John said, you know your system and have to figure out the impact issues. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bob Woodward Sent: Thursday, April 21, 2011 10:00 AM To: U2 Users List Subject: Re: [U2] Very Weird Trigger Behavior Then there is the possibility of adding another trigger to the update of the TRADES file that builds a CODES.XRF cross reference file. You avoid the large nothing index, gives you a straight READ, plus it's an easy rebuild program. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R. Sent: Thursday, April 21, 2011 9:52 AM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior Not knowing the size of the original files, as long as they are not too big, adding an index just to get a trigger to work might be serious overkill. You would need to make that call as only you know the size and performance hits involved in this. Just my 2 cents worth (1 cent in this economy). John Israel Senior Programmer/Analyst Dayton Superior Corporation 1125 Byers Road Miamisburg, OH 45342 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Wolverton Sent: Thursday, April 21, 2011 12:45 PM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior I would agree -- if there is an active select list, then you would get some seriously unexpected behavior doing another select unless you 'pushed' that new select to a different 'List ID' than the default '0' list -- just ensure it's a ListID that you KNOW would never be used anywhere else. Back to the 'ideal' - the index is the 'best answer' as it will be faster AND it would avoid the entire 'select' in the first place. The downside of the index may be the in the use of this code -- if every records ends up with a status of DONE, you probably would hate to index that 'status' field since it would be a VERY large index for the DONE set of keys... DW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R. Sent: Thursday, April 21, 2011 10:10 AM To: 'U2 Users List' Subject: Re: [U2] Very Weird Trigger Behavior Just a thought would be to change your select to use the non-default active select list. For example, instead of: CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' try CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:' TO 2' If you are running in PICK flavor, change the SELECT to select to force it to run in native UniData flavor. I am not sure how this will work with the SYSTEM(11) command, but even if that does not work, there are other ways to test if anything was returned. Note that if you DO need to loop through this, you may need to change code to read from active select 2 (not the default). You might also want to do a CLEARSELECT (or CLEARSELECT 2). John Israel Senior Programmer/Analyst Dayton Superior Corporation 1125 Byers Road Miamisburg, OH 45342 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 11:03 AM To: u2-users@listserver.u2ug.org Subject: [U2] Very Weird Trigger Behavior Hi, all. I'm new to this forum, but have been programming multivalue database apps for years. I ran across something here that really has me puzzled. I wonder if anyone has seen something like this and might be able to shed a bit of light as to what's happening. I'm running Unidata 6.0 on hpux. I have a trigger set up to run before deletions take place on a file called CODE_DEFS. The file just contains code numbers (ID) and their meaning/description. There's another file, TRADES, that contains a field, TRADE_CODE, that should have a many-to-one relationship with IDs in CODE_DEFS. That is, the content of TRADE_CODE should match a record ID in CODE_DEFS. Before a record is deleted from CODE_DEFS, I want to ensure its ID does not appear in any record in TRADES. That's where the trigger comes in. The trigger is passed the ID of the record to be deleted. This is done via parameter variable CODE_DEF_ID. The trigger program, CHECK_TRADES, has the following logic: --- . . . CMD='SELECT TRADES WITH TRADE_CODE = ':CODE_DEF_ID:'' EXECUTE CMD IF SYSTEM(11) THEN * there's a select list, so the code is still in use in TRADES. * Return 0 in EXECUTE_STATUS to disallow the
Re: [U2] Very Weird Trigger Behavior
COUNT would give you the wrong result if a select list was active at the time you executed it. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen Egerton Sent: Thursday, April 21, 2011 12:57 PM To: U2 Users List Subject: Re: [U2] Very Weird Trigger Behavior On 4/21/2011 11:03 AM, jonathanm wrote: Hi, all. I'm new to this forum, but have been programming multivalue database snip I really need to have it perform the intended check before deletion. Any ideas? Your execute of the SELECT will potentially result in an active select list that doesn't appear to be intentionally used. Since you don't want the ids, you just want to know if there are any, I'd do something like: CMD - 'COUNT TRADES WITH TRADE_CODE = ': CODE_DEF_ID: '' EXECUTE CMD CAPTURING CMD.CAP RETURNING CNT.SELECTED IF (CNT.SELECTED GT 0) THEN EXECUTE_STATUS = 0 END ELSE EXECUTE_STATUS = END I also don't know what you're doing with EXECUTE_STATUS, but if it's not set by the caller, it needs to be set here, otherwise its value is undetermined, (and in most cases will be set to null). Regards. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users html body Dave Davis Team Lead, Ramp;D P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif] 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. /body /html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Thanks, all. A few things I've observed: 1. It doesn't matter what type of command is being EXECUTEd; the problem persists. I've tried the suggestions here, plus unrelated commands such as DATE or WHERE. It seems that anything EXECUTEd will cause the ID to be lost because the process is, I believe, shelling out to another environment. 2. The XLATE function would be great since it doesn't involve shelling out to another environment. However, it requires that I know an ID in TRADES that has a CODE_DEFS id in the TRADE_CODE field. Instead, I need to search for such an ID. 3. The SETINDEX seems to hold some hope, since it doesn't shell out and it gives me the answer to the question, Do any records exist with such-and-such value in TRADE_CODE? I'll give it a shot. Thanks for all the suggestions so far. I'll let you know what the results are. Jonathan -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31451269.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Do you have any problem when using a UniBasic DELETE instead of an ECL DELETE? Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 11:25 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Very Weird Trigger Behavior Thanks, all. A few things I've observed: 1. It doesn't matter what type of command is being EXECUTEd; the problem persists. I've tried the suggestions here, plus unrelated commands such as DATE or WHERE. It seems that anything EXECUTEd will cause the ID to be lost because the process is, I believe, shelling out to another environment. 2. The XLATE function would be great since it doesn't involve shelling out to another environment. However, it requires that I know an ID in TRADES that has a CODE_DEFS id in the TRADE_CODE field. Instead, I need to search for such an ID. 3. The SETINDEX seems to hold some hope, since it doesn't shell out and it gives me the answer to the question, Do any records exist with such-and-such value in TRADE_CODE? I'll give it a shot. Thanks for all the suggestions so far. I'll let you know what the results are. Jonathan -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31451269.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Not knowing when the trigger were being called, even the COUNT would be 'dinged' if there is an active SELECT list. That would be a problem! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen Egerton Sent: Thursday, April 21, 2011 11:57 AM To: U2 Users List Subject: Re: [U2] Very Weird Trigger Behavior On 4/21/2011 11:03 AM, jonathanm wrote: Hi, all. I'm new to this forum, but have been programming multivalue database snip I really need to have it perform the intended check before deletion. Any ideas? Your execute of the SELECT will potentially result in an active select list that doesn't appear to be intentionally used. Since you don't want the ids, you just want to know if there are any, I'd do something like: CMD - 'COUNT TRADES WITH TRADE_CODE = ': CODE_DEF_ID: '' EXECUTE CMD CAPTURING CMD.CAP RETURNING CNT.SELECTED IF (CNT.SELECTED GT 0) THEN EXECUTE_STATUS = 0 END ELSE EXECUTE_STATUS = END I also don't know what you're doing with EXECUTE_STATUS, but if it's not set by the caller, it needs to be set here, otherwise its value is undetermined, (and in most cases will be set to null). ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Nice catch, Wally. It appears to work for a UniBasic DELETE, but definitely not for the ECL DELETE. I suppose that is because the UniBasic runtime environment does not share its symbol table with the shelled EXECUTEd environment, so overwriting system variables (ID, filename) doesn't matter. Is there anything that can be done about the ECL DELETE situation? Wally Terhune-2 wrote: Do you have any problem when using a UniBasic DELETE instead of an ECL DELETE? -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31452058.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Uh, don't grant your users ECL access? :-) Feel free to submit this request via your U2 support provider. Not sure how easily it could be accomplished, but we will give it consideration when it percolates up to me. Certainly nothing we would fix at your old release level (6.0.unknown) - even if we could. Ps - we recently worked with something similar regarding these global variables, but at first glance - it seems likely to be somewhat different than your situation: Addressed at UniData release 7.2.7: Issue 12476 - Problem Description UniBasic -- If a UniBasic subroutine was called by a virtual field, the value of the @ID may have become corrupted. The @ID value was changed to the last key of the file if the subroutine used the EXECUTE command to perform a SELECT of this file and used a WITH clause. For this problem to occur, at least two dictionary items calling a subroutine that included the @ID as an input argument had to be present in the SELECT statement. This problem has been fixed. __ Regards, Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jonathanm Sent: Thursday, April 21, 2011 1:29 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Very Weird Trigger Behavior Nice catch, Wally. It appears to work for a UniBasic DELETE, but definitely not for the ECL DELETE. I suppose that is because the UniBasic runtime environment does not share its symbol table with the shelled EXECUTEd environment, so overwriting system variables (ID, filename) doesn't matter. Is there anything that can be done about the ECL DELETE situation? Wally Terhune-2 wrote: Do you have any problem when using a UniBasic DELETE instead of an ECL DELETE? -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31452058.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
We are doing this with a county and zip file - the trigger is on the county file and a record cannot be deleted if it's referenced in the zip file: SUBROUTINE TRIG.COUNTY.DEL (EXECSTAT, DICTFLAG, FILENAME, COUNTY_ID) EQU DELETE_DENIED TO 0 EQU DELETE_ALLOWED TO 1 EXECSTAT = DELETE_DENIED IF (UNASSIGNED(FILENAME) OR (FILENAME NE COUNTY)) THEN RETURN END IF (UNASSIGNED(COUNTY_ID) OR (TRIM(COUNTY_ID) EQ )) THEN RETURN END CMD = 'SELECT P_ZIP WITH COUNTY_ID EQ ':COUNTY_ID:'' ZIP_LIST = EXECUTE CMD RTNLIST ZIP_LIST CAPTURING OUTPUT IF @SYSTEM.RETURN.CODE EQ 0 THEN EXECSTAT = DELETE_ALLOWED END RETURN Shaun Ferguson Applications Architect I Wolseley Group Services - 12500 Jefferson Avenue - Newport News - VA - 23602-4314 T: (757) 989-2916 - F: (757) 989-2801 - E: shaun.fergu...@wolseley.com www.wolseley.com blocked::http://www.wolseley.com/ Wolseley plc registered office Parkview 1220 Arlington Business Park Theale Nr Reading RG7 4GA United Kingdom Registration No. 29846 England ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
The one risk I see here is if you are at TCL and have a bunch of keys in an active select that you are going to delete. If THAT select list is not loaded into one of the higher active select buffers (i.e. 1-9), you will have some nightmares when the SELECT in the trigger clobbers the SELECT from TCL. Just the risks we all need to keep in mind. John Israel Senior Programmer/Analyst Dayton Superior Corporation 1125 Byers Road Miamisburg, OH 45342 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of shaun.fergu...@ferguson.com Sent: Thursday, April 21, 2011 3:42 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Very Weird Trigger Behavior We are doing this with a county and zip file - the trigger is on the county file and a record cannot be deleted if it's referenced in the zip file: SUBROUTINE TRIG.COUNTY.DEL (EXECSTAT, DICTFLAG, FILENAME, COUNTY_ID) EQU DELETE_DENIED TO 0 EQU DELETE_ALLOWED TO 1 EXECSTAT = DELETE_DENIED IF (UNASSIGNED(FILENAME) OR (FILENAME NE COUNTY)) THEN RETURN END IF (UNASSIGNED(COUNTY_ID) OR (TRIM(COUNTY_ID) EQ )) THEN RETURN END CMD = 'SELECT P_ZIP WITH COUNTY_ID EQ ':COUNTY_ID:'' ZIP_LIST = EXECUTE CMD RTNLIST ZIP_LIST CAPTURING OUTPUT IF @SYSTEM.RETURN.CODE EQ 0 THEN EXECSTAT = DELETE_ALLOWED END RETURN Shaun Ferguson Applications Architect I Wolseley Group Services - 12500 Jefferson Avenue - Newport News - VA - 23602-4314 T: (757) 989-2916 - F: (757) 989-2801 - E: shaun.fergu...@wolseley.com www.wolseley.com blocked::http://www.wolseley.com/ Wolseley plc registered office Parkview 1220 Arlington Business Park Theale Nr Reading RG7 4GA United Kingdom Registration No. 29846 England ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Wally Terhune-2 wrote: Uh, don't grant your users ECL access? :-) I've often said the computer system would work fine if we could keep people off of it. Wally Terhune-2 wrote: Feel free to submit this request via your U2 support provider. Not sure how easily it could be accomplished, but we will give it consideration when it percolates up to me. Certainly nothing we would fix at your old release level (6.0.unknown) - even if we could. Unfortunately, the company I'm contracting with has no provider relationship. Is there any way we submit it directly? Wally Terhune-2 wrote: Ps - we recently worked with something similar regarding these global variables, but at first glance - it seems likely to be somewhat different than your situation: Addressed at UniData release 7.2.7: Issue 12476 - Problem Description UniBasic -- If a UniBasic subroutine was called by a virtual field, the value of the @ID may have become corrupted. The @ID value was changed to the last key of the file if the subroutine used the EXECUTE command to perform a SELECT of this file and used a WITH clause. For this problem to occur, at least two dictionary items calling a subroutine that included the @ID as an input argument had to be present in the SELECT statement. This problem has been fixed. Hmmm. It certainly could be related, since the @ID and @FILE.NAME variables available in virtual fields certainly reference some deeper environment variable in the Unidata shell. Thanks for the enlightenment. :) -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31452195.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Wow! This is really similar to what I'm trying to do. What is your: OS, Unidata version, BASICTYPE? Also, are you having success with both ECL DELETEs and UniBasic DELETEs? Thanks! Jonathan Shaun.Ferguson wrote: We are doing this with a county and zip file - the trigger is on the county file and a record cannot be deleted if it's referenced in the zip file: SUBROUTINE TRIG.COUNTY.DEL (EXECSTAT, DICTFLAG, FILENAME, COUNTY_ID) EQU DELETE_DENIED TO 0 EQU DELETE_ALLOWED TO 1 EXECSTAT = DELETE_DENIED IF (UNASSIGNED(FILENAME) OR (FILENAME NE COUNTY)) THEN RETURN END IF (UNASSIGNED(COUNTY_ID) OR (TRIM(COUNTY_ID) EQ )) THEN RETURN END CMD = 'SELECT P_ZIP WITH COUNTY_ID EQ ':COUNTY_ID:'' ZIP_LIST = EXECUTE CMD RTNLIST ZIP_LIST CAPTURING OUTPUT IF @SYSTEM.RETURN.CODE EQ 0 THEN EXECSTAT = DELETE_ALLOWED END RETURN Shaun Ferguson Applications Architect I Wolseley Group Services - 12500 Jefferson Avenue - Newport News - VA - 23602-4314 T: (757) 989-2916 - F: (757) 989-2801 - E: shaun.fergu...@wolseley.com www.wolseley.com blocked::http://www.wolseley.com/ Wolseley plc registered office Parkview 1220 Arlington Business Park Theale Nr Reading RG7 4GA United Kingdom Registration No. 29846 England ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31452216.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Very Weird Trigger Behavior
Good word of caution, John. Thanks. Israel, John R. wrote: The one risk I see here is if you are at TCL and have a bunch of keys in an active select that you are going to delete. If THAT select list is not loaded into one of the higher active select buffers (i.e. 1-9), you will have some nightmares when the SELECT in the trigger clobbers the SELECT from TCL. Just the risks we all need to keep in mind. -- View this message in context: http://old.nabble.com/Very-Weird-Trigger-Behavior-tp31450305p31452224.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Saying Goodbye...
Know the feeling. There is only so much rejection one can take. Martin Scholl 18910 New Hampshire Ave Brinklow, MD 20862 301-924-5537 301-613-9572 (Cell) -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Karl Pearson Sent: Friday, May 28, 2010 12:29 AM To: U2 Users List Subject: [U2] Saying Goodbye... I'm not sure if most, or any, of you actually know me, but here's what amounts to my swan song. For the past 18+ years I've been a decent UV DBA. I took classes from Mark Baldridge and later Joel Yates way back when to learn how to manually repair corrupt files, and was proficient before uniVerse became so stable that corrupt files happened infrequently and fixtool worked. But during that time, I've maintained a personal email and web server, running Majordomo v1.94.5, etc. and have learned a bit about the LAMP stack in so doing. I've been a layed-off DBA, for a small retail company, for the past 22 months, consulting my previous employer because they got rid of me so they could have salary cap to hire a different type of IT manager and move off UV to Profit21, which failed after $250,000 lost. They are back on UV and will stay now. I, however, have to move on because I've received the proverbial offer one can't refuse ($5000US signing bonus and the option for 5000 shares of company stock), plus no one in the 'PICK' world has offered me anything, though there may be a few things still in the works, which will now go quietly away. I will be working in the LAMP world now, making a living doing my hobby, so to speak. (FYI: LAMP = Linux, Apache, MySQL and PHP or Perl, depending on who you listen to) I may hang around on the list for a bit, but will eventually have to unsubscribe as my life moves farther and father away from a field I have grown to respect and enjoy. Best wishes to all of you, and like others before me, I'm sure I'll miss the group association you've provided, though I'm mostly just a quiet observer. Thanks and I'll never forget this group of intelligent, insightful, thought-provoking and often entertaining, professionals. --- Karl Pearson ka...@ourldsfamily.com Owner/Administrator of the sites at http://ourldsfamily.com --- To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it. --- Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote. --Benjamin Franklin --- Children seldom misquote you. In fact, they usually repeat word for word what you shouldn't have said. --- ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.819 / Virus Database: 271.1.1/2879 - Release Date: 05/27/10 02:25:00 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Saying Goodbye...
Adiós mi amigo. Te veré en el lado oscuro de la luna. I myself am studying Thinking in Java Quite frankly I enjoy PICK so much more. OOP is just too close to Ops! But when I search for pick jobs in a 50 mile radius of my house there's just nada. When I search for Java within 10 miles of my house there are 201 jobs. It was a great gig... The best gig. But I no longer hear the music playing. Allen E. Elwood Tortilla Flats Consulting The Valley, SoCal (btw, remember I sent you that awesome Brushetta sauce recipe for salmon back in 2005-ish? Still my fav) -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin Scholl Sent: Thursday, April 21, 2011 6:51 PM To: 'U2 Users List' Subject: Re: [U2] Saying Goodbye... Know the feeling. There is only so much rejection one can take. Martin Scholl 18910 New Hampshire Ave Brinklow, MD 20862 301-924-5537 301-613-9572 (Cell) -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Karl Pearson Sent: Friday, May 28, 2010 12:29 AM To: U2 Users List Subject: [U2] Saying Goodbye... I'm not sure if most, or any, of you actually know me, but here's what amounts to my swan song. For the past 18+ years I've been a decent UV DBA. I took classes from Mark Baldridge and later Joel Yates way back when to learn how to manually repair corrupt files, and was proficient before uniVerse became so stable that corrupt files happened infrequently and fixtool worked. But during that time, I've maintained a personal email and web server, running Majordomo v1.94.5, etc. and have learned a bit about the LAMP stack in so doing. I've been a layed-off DBA, for a small retail company, for the past 22 months, consulting my previous employer because they got rid of me so they could have salary cap to hire a different type of IT manager and move off UV to Profit21, which failed after $250,000 lost. They are back on UV and will stay now. I, however, have to move on because I've received the proverbial offer one can't refuse ($5000US signing bonus and the option for 5000 shares of company stock), plus no one in the 'PICK' world has offered me anything, though there may be a few things still in the works, which will now go quietly away. I will be working in the LAMP world now, making a living doing my hobby, so to speak. (FYI: LAMP = Linux, Apache, MySQL and PHP or Perl, depending on who you listen to) I may hang around on the list for a bit, but will eventually have to unsubscribe as my life moves farther and father away from a field I have grown to respect and enjoy. Best wishes to all of you, and like others before me, I'm sure I'll miss the group association you've provided, though I'm mostly just a quiet observer. Thanks and I'll never forget this group of intelligent, insightful, thought-provoking and often entertaining, professionals. --- Karl Pearson ka...@ourldsfamily.com Owner/Administrator of the sites at http://ourldsfamily.com --- To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it. --- Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote. --Benjamin Franklin --- Children seldom misquote you. In fact, they usually repeat word for word what you shouldn't have said. --- ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.819 / Virus Database: 271.1.1/2879 - Release Date: 05/27/10 02:25:00 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Saying Goodbye...
Karl, I never knew thee, but I wish you the absolute best. Whatever your career takes you, own your future! -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
