For this reason its good to build a small form that keeps a tab on used ID's.. While it is ok to use ID's that are same across the forms, its good to make sure that the same ID contains similar data. For e.g. if you have a field called Requester Date of Birth with ID 600000001, if this date of birth is to be used in any other form by any other name like Date of birth or Birthday or whatever but if it represents the date of birth for that user, it would be good to have the same ID for that form too.
I generally tend to keep the DB name for that field the same across all forms too.. Change the label name if need be. Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of J.T. Shyman Sent: Thursday, March 13, 2008 12:00 PM To: [email protected] Subject: Re: What specifically breaks upgrades? ** The range of usable IDs for fields is actually huge (see below) and a field ID isn’t global across all forms; it is unique within the form. Just because there isn’t a 600000001 on one form doesn’t mean there isn’t a 600000001 on another form. From the “Form and Application Objects” guide a field database ID: Identifies the field internally throughout AR System. Every field in a form must have an integer field ID that is unique in that form. If you leave the ID field empty or set it to zero when you are defining a field, AR System will automatically assign a number from the unrestricted number set. Restrictions on field ID numbers are as follows: _ Numbers 1–99 are reserved for core fields. You cannot assign an ID in this range, unless you are modifying core fields. See Appendix A, “Core fields” for information about these fields. _ Numbers 100–536870912 are reserved. If you use an ID in this range, you will receive a warning. Numbers 1000000–1999999 and 3000000–3999999 are specifically reserved for regular global fields and window-scoped global fields, respectively. For more information about global fields, see page 218. _ Numbers 536870913–2147483647 are administrator-defined. There are no restrictions on assigning numbers in this range. If you choose to assign field IDs instead of letting AR System do it automatically, be aware that view IDs are also drawn from the low end of this range. Columns in table fields and pages in page fields also have an ID. For purposes of assigning order in workflow, you can assign the ID yourself, or let AR System assign the number for you. The field ID remains constant even if the database name or display label changes. You cannot modify the field ID after it is applied to the database. If you are defining fields that serve the same purpose in more than one form, assign identical IDs to the identical fields in the different forms. You can then write workflow once for that field (with minor edits to AR System field definition) and reuse the field in multiple forms. Reusing the ID provides a consistent definition for the field across the forms. As long as all of your custom fields are in this range you should be okay. However, if BMC decides to change this range in a future version they will probably take numbers from the low end first. This is why it is recommended to put custom fields higher in the range…like around 600,000,000 or even 800,000,000 --- J.T. Shyman ---------------------------------------------------------------------------- -- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Moore, Christopher Allen Sent: Thursday, March 13, 2008 10:59 AM To: [email protected] Subject: Re: What specifically breaks upgrades? Thanks JT- I used 600,000,001 and no error that time. However that implies that no one else here has ever done that, meaning we could have a mess on our hands at upgrade time… Chris ---------------------------------------------------------------------------- -- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of J.T. Shyman Sent: Thursday, March 13, 2008 9:42 AM To: [email protected] Subject: Re: What specifically breaks upgrades? I think Joe missed a word. It should be in the 6 hundred million range. (600000000-699999999) --- J.T. Shyman No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.21.7/1328 - Release Date: 3/13/2008 11:31 AM _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
