Re: Message not in catalog -- message number = 9070
Hi Folks, Thanks for your continued interest in this thread. I did check the SQL logs to see what happens when I update the User form Password field (FID 102) using the join form with the corresponding field renumbered to something other than FID 102... it does not encrypt the contents, neither in the SQL UPDATE nor in the database table. The password is sent in clear text. When the password field in the join retains it's FID=102, everything works correctly and the result is encrypted all the way to the database table. As an interesting aside, the user_cache entry is encrypted in both cases described above. So in my case, renumbering the Password field on the join form turned out to be a poor choice. That really only left me one field that I could renumber to avoid the 9070 error... Login Name (FID 101). I have renumbered Login Name on my join and everything seems to be working as expected. Hope this is helpful. Larry On Jan 18, 2011, at 10:25 AM, Misi Mladoniczky wrote: Hi, I suspect that if the field id is not 102, it will not encrypt the content before it is sent over the network. The SQL log will still show it encrypted though, as it is encrypted by the server before it is stored. It would be complicated to track the 102 to the actual regular form, as a join may be implemented in multiple tiers. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Hi Misi, I have not checked the SQL logs but I was assuming (hoping) that since the renumbered password field (on the join form) still maps to the real password field in the real User form (with it's original FID), then it would still be treated as such and encrypted as appropriate. I did in fact set the Display-Type to Edit Masked as you suggest and that part works just fine. If I get a few minutes today, I'll check the SQL logs to see what is getting sent. Thanks. Larry On Jan 18, 2011, at 3:54 AM, Misi Mladoniczky wrote: Hi, All else to the side, in this case, couldn't you just set the Display-Type to Edit Masked? I an guessing that it changes the way modified data is sent to the server, as the password field is normally sent encrypted. In the old days, I sometimes renamed the User-form to a Swedish equivalent, which worked just fine, and it probably still does. If you had multiple User-forms the system could suddenly switch forms, for example when you imported a record into UserCopy, the user cache could get reset with only the newly imported user in it... I am sure it worked like this in version 2.0 and 2.1, and possibly a bit after that as well ;-) Why is the 9070 message missing from the Error Message Guide? Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Message not in catalog -- message number = 9070
Hi, All else to the side, in this case, couldn't you just set the Display-Type to Edit Masked? I an guessing that it changes the way modified data is sent to the server, as the password field is normally sent encrypted. In the old days, I sometimes renamed the User-form to a Swedish equivalent, which worked just fine, and it probably still does. If you had multiple User-forms the system could suddenly switch forms, for example when you imported a record into UserCopy, the user cache could get reset with only the newly imported user in it... I am sure it worked like this in version 2.0 and 2.1, and possibly a bit after that as well ;-) Why is the 9070 message missing from the Error Message Guide? Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Hi Doug, Thanks for the explanation. It is very helpful to know what is going on in the background. Since 104 is the only one that I need that has special functionality, renumbering one or more of the others works fine as a workaround. Thanks again. Larry On Jan 17, 2011, at 2:36 PM, Mueller, Doug wrote: Larry, The User form (and several other system forms) is identified by the presence of a specific set of fields. If we find all the fields of a set on a form, the form is that special form with special meaning. If we find multiple forms with those fields, we don't know which is which and for key forms, we have logic that detects the confusion and you get the error 9070 indicating you cannot do what you are attempting because the form would cause confusion in the system. For the User form, The key fields include 101 and 102 and probably 104 and maybe 106 (I don't remember the exact list). If ALL of these fields are present on the form, it means the form is THE user form for the system. You will get the error when adding the last of whatever the set of special fields are so it could come reported against any one of the special fields -- whichever is added last. This is why renumbering the field doesn't have the problem. This is why adding some but not all of the fields doesn't have the problem. Only if you add ALL of the fields that the system is using to identify the form do you have the problem. Again, I don't remember the specific list of fields that identify the User form, but it is some combination of 101, 102, 104, and 106. (at least I think so) Doug Mueller -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of L G Robinson Sent: Friday, January 14, 2011 6:51 AM To: arslist@ARSLIST.ORG Subject: Re: Message not in catalog -- message number = 9070 Hi Folks, Well, I figured it out, but I still don't understand why it works the way it does. I created a new regular form and a new join form and I was able to include the Group List field from the User form. So that told me that there was something weird with my other forms that was preventing it from working correctly. So I saved a copy of my problematic join form, added the Group List field and then started to methodically delete other fields from the join until it saved. Turns out that it was the Password field (102) from the User form that was causing the collision. If the password field was not present, the join would save. If I added it back in so that the Password and the Group List fields were both present, I would get the 9070 error again. If I changed the FID of the Password field on the join form before saving, choosing a FID in the 5368709xx range, then it would save. So I have a workaround, but I still don't understand why it works this way. Any insights? Thanks. Larry On Jan 13, 2011, at 4:51 PM, L G Robinson wrote: Hi Folks, Does anyone know what error number 9070 means? It is not listed in my error messages manual. I receive this error when I attempt to add the Group List field (FID:104) to a join form that I am developing. My support folks tell me that there isn't anything special about FID 104 that should prevent me from adding it to the join. If I remove that field, the form will save just fine. Message not in catalog -- message number = 9070 : 104, 9070, NCSUUsers NCSUUsers is the name of the join form. It appears to be something specific about 104. If I change the field id before saving the form, it will save but of course, then the field does not display correctly. It displays the group id number(s) instead of the group name(s), which is inherent in the functionality of field 104. There is no other field on the join form with an id of 104. ARS: 7.6.03 Solaris: 10 Oracle: 11.2.0.1.0 - 64bit Production Thanks. Larry Larry
Re: Message not in catalog -- message number = 9070
Hi Misi, I have not checked the SQL logs but I was assuming (hoping) that since the renumbered password field (on the join form) still maps to the real password field in the real User form (with it's original FID), then it would still be treated as such and encrypted as appropriate. I did in fact set the Display-Type to Edit Masked as you suggest and that part works just fine. If I get a few minutes today, I'll check the SQL logs to see what is getting sent. Thanks. Larry On Jan 18, 2011, at 3:54 AM, Misi Mladoniczky wrote: Hi, All else to the side, in this case, couldn't you just set the Display-Type to Edit Masked? I an guessing that it changes the way modified data is sent to the server, as the password field is normally sent encrypted. In the old days, I sometimes renamed the User-form to a Swedish equivalent, which worked just fine, and it probably still does. If you had multiple User-forms the system could suddenly switch forms, for example when you imported a record into UserCopy, the user cache could get reset with only the newly imported user in it... I am sure it worked like this in version 2.0 and 2.1, and possibly a bit after that as well ;-) Why is the 9070 message missing from the Error Message Guide? Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Hi Doug, Thanks for the explanation. It is very helpful to know what is going on in the background. Since 104 is the only one that I need that has special functionality, renumbering one or more of the others works fine as a workaround. Thanks again. Larry On Jan 17, 2011, at 2:36 PM, Mueller, Doug wrote: Larry, The User form (and several other system forms) is identified by the presence of a specific set of fields. If we find all the fields of a set on a form, the form is that special form with special meaning. If we find multiple forms with those fields, we don't know which is which and for key forms, we have logic that detects the confusion and you get the error 9070 indicating you cannot do what you are attempting because the form would cause confusion in the system. For the User form, The key fields include 101 and 102 and probably 104 and maybe 106 (I don't remember the exact list). If ALL of these fields are present on the form, it means the form is THE user form for the system. You will get the error when adding the last of whatever the set of special fields are so it could come reported against any one of the special fields -- whichever is added last. This is why renumbering the field doesn't have the problem. This is why adding some but not all of the fields doesn't have the problem. Only if you add ALL of the fields that the system is using to identify the form do you have the problem. Again, I don't remember the specific list of fields that identify the User form, but it is some combination of 101, 102, 104, and 106. (at least I think so) Doug Mueller ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Message not in catalog -- message number = 9070
Hi, I suspect that if the field id is not 102, it will not encrypt the content before it is sent over the network. The SQL log will still show it encrypted though, as it is encrypted by the server before it is stored. It would be complicated to track the 102 to the actual regular form, as a join may be implemented in multiple tiers. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Hi Misi, I have not checked the SQL logs but I was assuming (hoping) that since the renumbered password field (on the join form) still maps to the real password field in the real User form (with it's original FID), then it would still be treated as such and encrypted as appropriate. I did in fact set the Display-Type to Edit Masked as you suggest and that part works just fine. If I get a few minutes today, I'll check the SQL logs to see what is getting sent. Thanks. Larry On Jan 18, 2011, at 3:54 AM, Misi Mladoniczky wrote: Hi, All else to the side, in this case, couldn't you just set the Display-Type to Edit Masked? I an guessing that it changes the way modified data is sent to the server, as the password field is normally sent encrypted. In the old days, I sometimes renamed the User-form to a Swedish equivalent, which worked just fine, and it probably still does. If you had multiple User-forms the system could suddenly switch forms, for example when you imported a record into UserCopy, the user cache could get reset with only the newly imported user in it... I am sure it worked like this in version 2.0 and 2.1, and possibly a bit after that as well ;-) Why is the 9070 message missing from the Error Message Guide? Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Hi Doug, Thanks for the explanation. It is very helpful to know what is going on in the background. Since 104 is the only one that I need that has special functionality, renumbering one or more of the others works fine as a workaround. Thanks again. Larry On Jan 17, 2011, at 2:36 PM, Mueller, Doug wrote: Larry, The User form (and several other system forms) is identified by the presence of a specific set of fields. If we find all the fields of a set on a form, the form is that special form with special meaning. If we find multiple forms with those fields, we don't know which is which and for key forms, we have logic that detects the confusion and you get the error 9070 indicating you cannot do what you are attempting because the form would cause confusion in the system. For the User form, The key fields include 101 and 102 and probably 104 and maybe 106 (I don't remember the exact list). If ALL of these fields are present on the form, it means the form is THE user form for the system. You will get the error when adding the last of whatever the set of special fields are so it could come reported against any one of the special fields -- whichever is added last. This is why renumbering the field doesn't have the problem. This is why adding some but not all of the fields doesn't have the problem. Only if you add ALL of the fields that the system is using to identify the form do you have the problem. Again, I don't remember the specific list of fields that identify the User form, but it is some combination of 101, 102, 104, and 106. (at least I think so) Doug Mueller ___ 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: Message not in catalog -- message number = 9070
Hi Doug, Thanks for the explanation. It is very helpful to know what is going on in the background. Since 104 is the only one that I need that has special functionality, renumbering one or more of the others works fine as a workaround. Thanks again. Larry On Jan 17, 2011, at 2:36 PM, Mueller, Doug wrote: Larry, The User form (and several other system forms) is identified by the presence of a specific set of fields. If we find all the fields of a set on a form, the form is that special form with special meaning. If we find multiple forms with those fields, we don't know which is which and for key forms, we have logic that detects the confusion and you get the error 9070 indicating you cannot do what you are attempting because the form would cause confusion in the system. For the User form, The key fields include 101 and 102 and probably 104 and maybe 106 (I don't remember the exact list). If ALL of these fields are present on the form, it means the form is THE user form for the system. You will get the error when adding the last of whatever the set of special fields are so it could come reported against any one of the special fields -- whichever is added last. This is why renumbering the field doesn't have the problem. This is why adding some but not all of the fields doesn't have the problem. Only if you add ALL of the fields that the system is using to identify the form do you have the problem. Again, I don't remember the specific list of fields that identify the User form, but it is some combination of 101, 102, 104, and 106. (at least I think so) Doug Mueller -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of L G Robinson Sent: Friday, January 14, 2011 6:51 AM To: arslist@ARSLIST.ORG Subject: Re: Message not in catalog -- message number = 9070 Hi Folks, Well, I figured it out, but I still don't understand why it works the way it does. I created a new regular form and a new join form and I was able to include the Group List field from the User form. So that told me that there was something weird with my other forms that was preventing it from working correctly. So I saved a copy of my problematic join form, added the Group List field and then started to methodically delete other fields from the join until it saved. Turns out that it was the Password field (102) from the User form that was causing the collision. If the password field was not present, the join would save. If I added it back in so that the Password and the Group List fields were both present, I would get the 9070 error again. If I changed the FID of the Password field on the join form before saving, choosing a FID in the 5368709xx range, then it would save. So I have a workaround, but I still don't understand why it works this way. Any insights? Thanks. Larry On Jan 13, 2011, at 4:51 PM, L G Robinson wrote: Hi Folks, Does anyone know what error number 9070 means? It is not listed in my error messages manual. I receive this error when I attempt to add the Group List field (FID:104) to a join form that I am developing. My support folks tell me that there isn't anything special about FID 104 that should prevent me from adding it to the join. If I remove that field, the form will save just fine. Message not in catalog -- message number = 9070 : 104, 9070, NCSUUsers NCSUUsers is the name of the join form. It appears to be something specific about 104. If I change the field id before saving the form, it will save but of course, then the field does not display correctly. It displays the group id number(s) instead of the group name(s), which is inherent in the functionality of field 104. There is no other field on the join form with an id of 104. ARS: 7.6.03 Solaris: 10 Oracle: 11.2.0.1.0 - 64bit Production Thanks. Larry Larry Robinson n...@ncsu.edu Office of Information Technology NC State University 919-515-5432 Voice Raleigh, NC 27695-7109 919-513-0877 FAX ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Message not in catalog -- message number = 9070
Hi Folks, Well, I figured it out, but I still don't understand why it works the way it does. I created a new regular form and a new join form and I was able to include the Group List field from the User form. So that told me that there was something weird with my other forms that was preventing it from working correctly. So I saved a copy of my problematic join form, added the Group List field and then started to methodically delete other fields from the join until it saved. Turns out that it was the Password field (102) from the User form that was causing the collision. If the password field was not present, the join would save. If I added it back in so that the Password and the Group List fields were both present, I would get the 9070 error again. If I changed the FID of the Password field on the join form before saving, choosing a FID in the 5368709xx range, then it would save. So I have a workaround, but I still don't understand why it works this way. Any insights? Thanks. Larry On Jan 13, 2011, at 4:51 PM, L G Robinson wrote: Hi Folks, Does anyone know what error number 9070 means? It is not listed in my error messages manual. I receive this error when I attempt to add the Group List field (FID:104) to a join form that I am developing. My support folks tell me that there isn't anything special about FID 104 that should prevent me from adding it to the join. If I remove that field, the form will save just fine. Message not in catalog -- message number = 9070 : 104, 9070, NCSUUsers NCSUUsers is the name of the join form. It appears to be something specific about 104. If I change the field id before saving the form, it will save but of course, then the field does not display correctly. It displays the group id number(s) instead of the group name(s), which is inherent in the functionality of field 104. There is no other field on the join form with an id of 104. ARS: 7.6.03 Solaris: 10 Oracle: 11.2.0.1.0 - 64bit Production Thanks. Larry Larry Robinson n...@ncsu.edu Office of Information Technology NC State University 919-515-5432 Voice Raleigh, NC 27695-7109 919-513-0877 FAX ___ 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: EXTERNAL: Re: Message not in catalog -- message number = 9070
Larry, I ran into this a few years back but I can't swear it was the same error message. There is something funky about using too many core fields in joins. My errors occurred when trying to send email notifications and I had field ids like 101, 103, 104 106 included in the join. My error message kept including the 106 field id as the problem but it was another core field that we removed because we needed to the Group ID. --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of L G Robinson Sent: Friday, January 14, 2011 9:51 AM To: arslist@ARSLIST.ORG Subject: EXTERNAL: Re: Message not in catalog -- message number = 9070 Hi Folks, Well, I figured it out, but I still don't understand why it works the way it does. I created a new regular form and a new join form and I was able to include the Group List field from the User form. So that told me that there was something weird with my other forms that was preventing it from working correctly. So I saved a copy of my problematic join form, added the Group List field and then started to methodically delete other fields from the join until it saved. Turns out that it was the Password field (102) from the User form that was causing the collision. If the password field was not present, the join would save. If I added it back in so that the Password and the Group List fields were both present, I would get the 9070 error again. If I changed the FID of the Password field on the join form before saving, choosing a FID in the 5368709xx range, then it would save. So I have a workaround, but I still don't understand why it works this way. Any insights? Thanks. Larry On Jan 13, 2011, at 4:51 PM, L G Robinson wrote: Hi Folks, Does anyone know what error number 9070 means? It is not listed in my error messages manual. I receive this error when I attempt to add the Group List field (FID:104) to a join form that I am developing. My support folks tell me that there isn't anything special about FID 104 that should prevent me from adding it to the join. If I remove that field, the form will save just fine. Message not in catalog -- message number = 9070 : 104, 9070, NCSUUsers NCSUUsers is the name of the join form. It appears to be something specific about 104. If I change the field id before saving the form, it will save but of course, then the field does not display correctly. It displays the group id number(s) instead of the group name(s), which is inherent in the functionality of field 104. There is no other field on the join form with an id of 104. ARS: 7.6.03 Solaris: 10 Oracle: 11.2.0.1.0 - 64bit Production Thanks. Larry Larry Robinson n...@ncsu.edu Office of Information Technology NC State University 919-515-5432 Voice Raleigh, NC 27695-7109 919-513-0877 FAX ___ 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: EXTERNAL: Re: Message not in catalog -- message number = 9070
Hi John, Apparently, it's a know issue: SW00380659 - ARERR 9070 - Message not in catalog while creating join with the User form I can't see any details on the defect but in my case, I was including several of the special fields from the User form including Login Name, Password, Group List and Assigned To. Fortunately, I was able to renumber the Password field on the join form without losing any inherent functionality, so I have a workaround. Hope this helps someone. Larry On Jan 14, 2011, at 12:11 PM, Reiser, John J wrote: Larry, I ran into this a few years back but I can't swear it was the same error message. There is something funky about using too many core fields in joins. My errors occurred when trying to send email notifications and I had field ids like 101, 103, 104 106 included in the join. My error message kept including the 106 field id as the problem but it was another core field that we removed because we needed to the Group ID. --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Message not in catalog -- message number = 9070
Hi Folks, Does anyone know what error number 9070 means? It is not listed in my error messages manual. I receive this error when I attempt to add the Group List field (FID:104) to a join form that I am developing. My support folks tell me that there isn't anything special about FID 104 that should prevent me from adding it to the join. If I remove that field, the form will save just fine. Message not in catalog -- message number = 9070 : 104, 9070, NCSUUsers NCSUUsers is the name of the join form. It appears to be something specific about 104. If I change the field id before saving the form, it will save but of course, then the field does not display correctly. It displays the group id number(s) instead of the group name(s), which is inherent in the functionality of field 104. There is no other field on the join form with an id of 104. ARS: 7.6.03 Solaris: 10 Oracle: 11.2.0.1.0 - 64bit Production Thanks. Larry Larry Robinson n...@ncsu.edu Office of Information Technology NC State University 919-515-5432 Voice Raleigh, NC 27695-7109 919-513-0877 FAX ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
