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 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"
