Re: GUID FIELD 179
Thank you everyone for the help. The documentation is a bit misleading So what else is new! :-) On Tue, Dec 7, 2010 at 2:41 AM, Scott Parrish sparr...@itprophets.comwrote: ** “If you issue the submit – and have not populated 179 – and then do a set fields in a filter say field-179-copy = $179$, I expect you will find a null on field-179-copy. (I have not done this.)” Well, I think you should. I think you’ll be surprised with the results. I never said that field 179 required a completed commit to the database. Yes, I said that about field Id 1. In that regard, I was wrong. Scott Parrish IT Prophets (770) 653-5203 www.itprophets.com *From:* Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] *Sent:* Tuesday, December 07, 2010 2:32 AM *To:* arslist@ARSLIST.ORG *Subject:* RE: GUID FIELD 179 Hi Scott, I am not wrong. If you issue the submit – and have not populated 179 – and then do a set fields in a filter say field-179-copy = $179$, I expect you will find a null on field-179-copy. (I have not done this.) Neither 1 not 179 require “a completed commit to the db”. They are set automatically by the arserver code before doing the update sql statement but after the set of filters (phase 1) have fired. In the case of 179 if and only if it is not in the transaction on the submit nor set by wf – possibly not set to null by wf. The only advantage of 179 (and it is a big advantage) is that you can build your child records before the parent is saved (hopefully remembering to clean up those children when the parent is not saved) by setting a value with wf before the set of filters are done – thereby allowing the server code to skip its setting. As for auto-populate, it works as I have described above since the invention of the field in 6.3 (as you correctly identified its introduction) with this from the 6.3 arstruct.h /* Reserved for the GUID (Globally Unique */ /* ID) field of the current schema object.*/ /* The field will be a character field*/ /* with the length of 38 characters. */ #define AR_RESERV_GUID179L I note the comments have not been changed since (up to 7.6.03) though indeed the “Global-ness” aspects have been improved as have the database SQL issues with its early releases. Note also that it MUST be 38 characters else it is NOT considered a GUID field for auto-population. Cheers Ben Ben Chernys Senior Software Architect Software Tool House Inc. Canada / Deutschland / Germany Mobile: +49 171 380 2329GMT + 1 + [ DST ] Email: Ben.Chernys _AT_ softwaretoolhouse.comben.cher...@softwaretoolhouse.com Web: www.softwaretoolhouse.com Check out Software Tool House's free Diary Editor. *Meta-Update**,* our premium ARS Data tool, lets you automate your imports, migrations, *in no time at all*, without programming, without staging forms, without merge workflow. http://www.softwaretoolhouse.com/ www.softwaretoolhouse.com *From:* Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] *On Behalf Of *Scott Parrish *Sent:* December-07-10 06:48 *To:* arslist@ARSLIST.ORG *Subject:* Re: GUID FIELD 179 ** All, I believe the confusion surrounding field ID 179 is this: Prior to ARS 6.3, if you wanted to use a GUID for creating parent/child relationships, the GUID had to be created using the Application-Generate-GUID process (there was no field Id 179). In ARS 6.3, Remedy introduced field ID 179. This field is auto-populated by the system and is available throughout all three phases of filter processing (unlike the Request ID field). By adding field ID 179 to a form you can push the value of the field in a Phase 1 filter push that executes on submit (even though you have not specifically set the field’s value). In addition, the value is also available for any active link push fields that execute on Submit. Chris Woyton’s email below points out that the auto-population of this field does not work prior to 7.5. I cannot attest to whether it works in 6.3, but I know it works in 7.0 and above. Ben is correct, except that field ID 179 behaves differently than field ID 1. The value of field Id 179 is available immediately upon submit (population of the field does not rely upon the completed commit to the database). I hope I have not further confused the situation. Scott Parrish IT Prophets (770) 653-5203 www.itprophets.com *From:* Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] *On Behalf Of *Ben Chernys *Sent:* Tuesday, December 07, 2010 12:29 AM *To:* arslist@ARSLIST.ORG *Subject:* Re: GUID FIELD 179 ** The GUID field has always (since its invention) been automatically populated
GUID FIELD 179
ARS 6.3 on a Sun Solaris system and Oracle 10.x Quick question. It's been awhile since I've done this, I've build a GUID field (ID 179) on a request form.. it's my understanding that this would make the GUID available prior to submitting the ticket, however that doesnt seem to be the case. Am I missing something? the Remedy helpfile defines GUID Fields as: To auto-populate a field with a GUID, define a character field using field ID 179. A GUID is available during active link processing on the client and through all filter phases. By contrast, the value of Request ID field is not available until an entry has been successfully committed to the database. You can set the attributes of the GUID field, except for field type, length, and ID. This suggests to me that it should be available from a new form. However the only way I can get it is to generate it with a $PROCESS$ @@:Application-Generate-GUID. Could someone enlighten me? -- Warren R. Baltimore II Remedy Developer 410-533-5367 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: GUID FIELD 179
The presence of the field does not mean that the value is available before the record is submitted to the db. You need to use the run process command to populate a guid in the field prior to the record being submitted if you need that value before the record is submitted. On Mon, Dec 6, 2010 at 10:13 AM, Warren Baltimore warrenbaltim...@gmail.com wrote: ** ARS 6.3 on a Sun Solaris system and Oracle 10.x Quick question. It's been awhile since I've done this, I've build a GUID field (ID 179) on a request form.. it's my understanding that this would make the GUID available prior to submitting the ticket, however that doesnt seem to be the case. Am I missing something? the Remedy helpfile defines GUID Fields as: To auto-populate a field with a GUID, define a character field using field ID 179. A GUID is available during active link processing on the client and through all filter phases. By contrast, the value of Request ID field is not available until an entry has been successfully committed to the database. You can set the attributes of the GUID field, except for field type, length, and ID. This suggests to me that it should be available from a new form. However the only way I can get it is to generate it with a $PROCESS$ @@:Application-Generate-GUID. Could someone enlighten me? -- Warren R. Baltimore II Remedy Developer 410-533-5367 _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: GUID FIELD 179
Potentially you could write an active link on say lose focus of a field to call $PROCESS$ @@:Application-Generate-GUID and set the output to a field on the form This way you will have the GUID created. Now when you save / submit the request then an entry will be created in database. This way you can have the GUID created even before a entry is created at the database level hope that helps Regards, Abhijeet The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. From: Action Request System discussion list(ARSList) [arsl...@arslist.org] On Behalf Of Warren Baltimore [warrenbaltim...@gmail.com] Sent: Monday, December 06, 2010 9:43 PM To: arslist@ARSLIST.ORG Subject: GUID FIELD 179 ** ARS 6.3 on a Sun Solaris system and Oracle 10.x Quick question. It's been awhile since I've done this, I've build a GUID field (ID 179) on a request form.. it's my understanding that this would make the GUID available prior to submitting the ticket, however that doesnt seem to be the case. Am I missing something? the Remedy helpfile defines GUID Fields as: To auto-populate a field with a GUID, define a character field using field ID 179. A GUID is available during active link processing on the client and through all filter phases. By contrast, the value of Request ID field is not available until an entry has been successfully committed to the database. You can set the attributes of the GUID field, except for field type, length, and ID. This suggests to me that it should be available from a new form. However the only way I can get it is to generate it with a $PROCESS$ @@:Application-Generate-GUID. Could someone enlighten me? -- Warren R. Baltimore II Remedy Developer 410-533-5367 _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: GUID FIELD 179
The GUID isn't automatically populated in earlier versions of ARS (I believe 7.5 is the first version which does). For lower versions you need to use a run process as you have been doing. Sounds like there's either a documentation bug or you're looking at a newer help file. On Mon, Dec 6, 2010 at 9:19 AM, Gadgil, Abhijeet abhijeet_gad...@bmc.comwrote: Potentially you could write an active link on say lose focus of a field to call $PROCESS$ @@:Application-Generate-GUID and set the output to a field on the form This way you will have the GUID created. Now when you save / submit the request then an entry will be created in database. This way you can have the GUID created even before a entry is created at the database level hope that helps Regards, Abhijeet The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. From: Action Request System discussion list(ARSList) [arsl...@arslist.org] On Behalf Of Warren Baltimore [warrenbaltim...@gmail.com] Sent: Monday, December 06, 2010 9:43 PM To: arslist@ARSLIST.ORG Subject: GUID FIELD 179 ** ARS 6.3 on a Sun Solaris system and Oracle 10.x Quick question. It's been awhile since I've done this, I've build a GUID field (ID 179) on a request form.. it's my understanding that this would make the GUID available prior to submitting the ticket, however that doesnt seem to be the case. Am I missing something? the Remedy helpfile defines GUID Fields as: To auto-populate a field with a GUID, define a character field using field ID 179. A GUID is available during active link processing on the client and through all filter phases. By contrast, the value of Request ID field is not available until an entry has been successfully committed to the database. You can set the attributes of the GUID field, except for field type, length, and ID. This suggests to me that it should be available from a new form. However the only way I can get it is to generate it with a $PROCESS$ @@:Application-Generate-GUID. Could someone enlighten me? -- Warren R. Baltimore II Remedy Developer 410-533-5367 _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: GUID FIELD 179
The GUID field has always (since its invention) been automatically populated ON SUBMIT - that is when all workflow has fired and the record is being written to the database - much like field 1. If you need it ahead of that (in filters or ALs) then you need to populate it. Cheers Ben Chernys www.softwaretoolhouse.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Chris Woyton Sent: December-07-10 05:14 To: arslist@ARSLIST.ORG Subject: Re: GUID FIELD 179 ** The GUID isn't automatically populated in earlier versions of ARS (I believe 7.5 is the first version which does). For lower versions you need to use a run process as you have been doing. Sounds like there's either a documentation bug or you're looking at a newer help file. On Mon, Dec 6, 2010 at 9:19 AM, Gadgil, Abhijeet abhijeet_gad...@bmc.com wrote: Potentially you could write an active link on say lose focus of a field to call $PROCESS$ @@:Application-Generate-GUID and set the output to a field on the form This way you will have the GUID created. Now when you save / submit the request then an entry will be created in database. This way you can have the GUID created even before a entry is created at the database level hope that helps Regards, Abhijeet The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. From: Action Request System discussion list(ARSList) [ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: GUID FIELD 179
All, I believe the confusion surrounding field ID 179 is this: Prior to ARS 6.3, if you wanted to use a GUID for creating parent/child relationships, the GUID had to be created using the Application-Generate-GUID process (there was no field Id 179). In ARS 6.3, Remedy introduced field ID 179. This field is auto-populated by the system and is available throughout all three phases of filter processing (unlike the Request ID field). By adding field ID 179 to a form you can push the value of the field in a Phase 1 filter push that executes on submit (even though you have not specifically set the field's value). In addition, the value is also available for any active link push fields that execute on Submit. Chris Woyton's email below points out that the auto-population of this field does not work prior to 7.5. I cannot attest to whether it works in 6.3, but I know it works in 7.0 and above. Ben is correct, except that field ID 179 behaves differently than field ID 1. The value of field Id 179 is available immediately upon submit (population of the field does not rely upon the completed commit to the database). I hope I have not further confused the situation. Scott Parrish IT Prophets (770) 653-5203 www.itprophets.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: Tuesday, December 07, 2010 12:29 AM To: arslist@ARSLIST.ORG Subject: Re: GUID FIELD 179 ** The GUID field has always (since its invention) been automatically populated ON SUBMIT - that is when all workflow has fired and the record is being written to the database - much like field 1. If you need it ahead of that (in filters or ALs) then you need to populate it. Cheers Ben Chernys www.softwaretoolhouse.comhttp://www.softwaretoolhouse.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Chris Woyton Sent: December-07-10 05:14 To: arslist@ARSLIST.ORG Subject: Re: GUID FIELD 179 ** The GUID isn't automatically populated in earlier versions of ARS (I believe 7.5 is the first version which does). For lower versions you need to use a run process as you have been doing. Sounds like there's either a documentation bug or you're looking at a newer help file. On Mon, Dec 6, 2010 at 9:19 AM, Gadgil, Abhijeet abhijeet_gad...@bmc.commailto:abhijeet_gad...@bmc.com wrote: Potentially you could write an active link on say lose focus of a field to call $PROCESS$ @@:Application-Generate-GUID and set the output to a field on the form This way you will have the GUID created. Now when you save / submit the request then an entry will be created in database. This way you can have the GUID created even before a entry is created at the database level hope that helps Regards, Abhijeet The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. From: Action Request System discussion list(ARSList) [ _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: GUID FIELD 179
Hi Scott, I am not wrong. If you issue the submit - and have not populated 179 - and then do a set fields in a filter say field-179-copy = $179$, I expect you will find a null on field-179-copy. (I have not done this.) Neither 1 not 179 require a completed commit to the db. They are set automatically by the arserver code before doing the update sql statement but after the set of filters (phase 1) have fired. In the case of 179 if and only if it is not in the transaction on the submit nor set by wf - possibly not set to null by wf. The only advantage of 179 (and it is a big advantage) is that you can build your child records before the parent is saved (hopefully remembering to clean up those children when the parent is not saved) by setting a value with wf before the set of filters are done - thereby allowing the server code to skip its setting. As for auto-populate, it works as I have described above since the invention of the field in 6.3 (as you correctly identified its introduction) with this from the 6.3 arstruct.h /* Reserved for the GUID (Globally Unique */ /* ID) field of the current schema object.*/ /* The field will be a character field */ /* with the length of 38 characters. */ #define AR_RESERV_GUID179L I note the comments have not been changed since (up to 7.6.03) though indeed the Global-ness aspects have been improved as have the database SQL issues with its early releases. Note also that it MUST be 38 characters else it is NOT considered a GUID field for auto-population. Cheers Ben Ben Chernys Senior Software Architect Software Tool House Inc. Canada / Deutschland / Germany Mobile: +49 171 380 2329GMT + 1 + [ DST ] Email:mailto:ben.cher...@softwaretoolhouse.com Ben.Chernys _AT_ softwaretoolhouse.com Web: http://www.softwaretoolhouse.com www.softwaretoolhouse.com Check out Software Tool House's free Diary Editor. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. http://www.softwaretoolhouse.com/ http://www.softwaretoolhouse.com/ www.softwaretoolhouse.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Scott Parrish Sent: December-07-10 06:48 To: arslist@ARSLIST.ORG Subject: Re: GUID FIELD 179 ** All, I believe the confusion surrounding field ID 179 is this: Prior to ARS 6.3, if you wanted to use a GUID for creating parent/child relationships, the GUID had to be created using the Application-Generate-GUID process (there was no field Id 179). In ARS 6.3, Remedy introduced field ID 179. This field is auto-populated by the system and is available throughout all three phases of filter processing (unlike the Request ID field). By adding field ID 179 to a form you can push the value of the field in a Phase 1 filter push that executes on submit (even though you have not specifically set the field's value). In addition, the value is also available for any active link push fields that execute on Submit. Chris Woyton's email below points out that the auto-population of this field does not work prior to 7.5. I cannot attest to whether it works in 6.3, but I know it works in 7.0 and above. Ben is correct, except that field ID 179 behaves differently than field ID 1. The value of field Id 179 is available immediately upon submit (population of the field does not rely upon the completed commit to the database). I hope I have not further confused the situation. Scott Parrish IT Prophets (770) 653-5203 www.itprophets.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: Tuesday, December 07, 2010 12:29 AM To: arslist@ARSLIST.ORG Subject: Re: GUID FIELD 179 ** The GUID field has always (since its invention) been automatically populated ON SUBMIT - that is when all workflow has fired and the record is being written to the database - much like field 1. If you need it ahead of that (in filters or ALs) then you need to populate it. Cheers Ben Chernys www.softwaretoolhouse.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Chris Woyton Sent: December-07-10 05:14 To: arslist@ARSLIST.ORG Subject: Re: GUID FIELD 179 ** The GUID isn't automatically populated in earlier versions of ARS (I believe 7.5 is the first version which does). For lower versions you need to use a run process as you have been doing. Sounds like there's either a documentation bug or you're looking at a newer help file. On Mon, Dec 6, 2010 at 9:19 AM, Gadgil, Abhijeet abhijeet_gad...@bmc.com wrote: Potentially you could write an active link on say lose
Re: GUID FIELD 179
If you issue the submit - and have not populated 179 - and then do a set fields in a filter say field-179-copy = $179$, I expect you will find a null on field-179-copy. (I have not done this.) Well, I think you should. I think you'll be surprised with the results. I never said that field 179 required a completed commit to the database. Yes, I said that about field Id 1. In that regard, I was wrong. Scott Parrish IT Prophets (770) 653-5203 www.itprophets.com From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] Sent: Tuesday, December 07, 2010 2:32 AM To: arslist@ARSLIST.ORG Subject: RE: GUID FIELD 179 Hi Scott, I am not wrong. If you issue the submit - and have not populated 179 - and then do a set fields in a filter say field-179-copy = $179$, I expect you will find a null on field-179-copy. (I have not done this.) Neither 1 not 179 require a completed commit to the db. They are set automatically by the arserver code before doing the update sql statement but after the set of filters (phase 1) have fired. In the case of 179 if and only if it is not in the transaction on the submit nor set by wf - possibly not set to null by wf. The only advantage of 179 (and it is a big advantage) is that you can build your child records before the parent is saved (hopefully remembering to clean up those children when the parent is not saved) by setting a value with wf before the set of filters are done - thereby allowing the server code to skip its setting. As for auto-populate, it works as I have described above since the invention of the field in 6.3 (as you correctly identified its introduction) with this from the 6.3 arstruct.h /* Reserved for the GUID (Globally Unique */ /* ID) field of the current schema object.*/ /* The field will be a character field */ /* with the length of 38 characters. */ #define AR_RESERV_GUID179L I note the comments have not been changed since (up to 7.6.03) though indeed the Global-ness aspects have been improved as have the database SQL issues with its early releases. Note also that it MUST be 38 characters else it is NOT considered a GUID field for auto-population. Cheers Ben Ben Chernys Senior Software Architect Software Tool House Inc. Canada / Deutschland / Germany Mobile: +49 171 380 2329GMT + 1 + [ DST ] Email: Ben.Chernys _AT_ softwaretoolhouse.commailto:ben.cher...@softwaretoolhouse.com Web: www.softwaretoolhouse.comhttp://www.softwaretoolhouse.com Check out Software Tool House's free Diary Editor. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. http://www.softwaretoolhouse.com/ www.softwaretoolhouse.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Scott Parrish Sent: December-07-10 06:48 To: arslist@ARSLIST.ORG Subject: Re: GUID FIELD 179 ** All, I believe the confusion surrounding field ID 179 is this: Prior to ARS 6.3, if you wanted to use a GUID for creating parent/child relationships, the GUID had to be created using the Application-Generate-GUID process (there was no field Id 179). In ARS 6.3, Remedy introduced field ID 179. This field is auto-populated by the system and is available throughout all three phases of filter processing (unlike the Request ID field). By adding field ID 179 to a form you can push the value of the field in a Phase 1 filter push that executes on submit (even though you have not specifically set the field's value). In addition, the value is also available for any active link push fields that execute on Submit. Chris Woyton's email below points out that the auto-population of this field does not work prior to 7.5. I cannot attest to whether it works in 6.3, but I know it works in 7.0 and above. Ben is correct, except that field ID 179 behaves differently than field ID 1. The value of field Id 179 is available immediately upon submit (population of the field does not rely upon the completed commit to the database). I hope I have not further confused the situation. Scott Parrish IT Prophets (770) 653-5203 www.itprophets.comhttp://www.itprophets.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: Tuesday, December 07, 2010 12:29 AM To: arslist@ARSLIST.ORG Subject: Re: GUID FIELD 179 ** The GUID field has always (since its invention) been automatically populated ON SUBMIT - that is when all workflow has fired and the record is being written to the database - much like field 1. If you need it ahead of that (in filters or ALs) then you need to populate it. Cheers Ben Chernys www.softwaretoolhouse.comhttp://www.softwaretoolhouse.com From: Action
