Answers.Body: <p>If you find yourself wanting to give really long custom field names, think about whether you really should have a fairly short label and then provide help text that goes along with the field.  </p>
  
  <p>Besides causing database problems (though CiviCRM largely handles that on its own by just cutting off the field name), you'll have trouble displaying a super-long field name on forms and in reports.</p>
  
  <p>For values, are you actually experiencing this problem?  If multiple choices are allowed in a field (let's say all those numbers are available as checkboxes), they're separated by a delimiter character in the database.  Searching for 2 won't pull a contact with 12, and searching for 12 won't show results that have both 1 and 2.</p>
  
  <p>In the field itself, the storage is like (not with an asterisk but an unprintable character) "*1*2*6*" for having 1, 2, and 6 checked.  It's stored like "*11*12*" for having 11 and 12 checked.  They're easily distinguished.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-06T21:00:21.497Z
Answers.Text: Try using a numeric list with a leading zero.... ala, 01, 02, 03, .... 09, 10, 11....
Answers.UserDisplayName: DaveD
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-05-28T10:49:02.650Z
Answers.Text: The delimiter is actually ASCII control character 001, see https://forum.civicrm.org/index.php%3Ftopic=26395.0.html
Answers.UserDisplayName: emma
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-25T08:34:45.357Z
Answers.Text: Yes I am experiencing this. If I make a multiple choice field, and later on making a report, selecting the option for value 2, I also get included in the result the options for 12
Answers.UserDisplayName: Flying
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-25T11:12:50.563Z
Answers.Text: You definitely have a problem in your site.  This isn't supposed to happen. Either there's an issue with your CiviCRM version or a site-specific problem.  One thing to check is your character encoding: maybe your system isn't adding that delimiter character to the saved values or using it to parse them.
Answers.UserDisplayName: Andie Hunt
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-25T14:02:10.950Z
Answers.Text: Agree, this is behaviour I have not experienced so strongly suspect there is a strange problem on your site. Have you checked the actual values in the option group related to the custom field? You can see them with 'Administer/System Settings/Option Groups'
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-26T18:01:49.687Z
Answers.Text: @AndrewHunt and ErikH Do any of you know if there is a setting somewhere where I should set such a delimiter character for custom multiselect fields?
Answers.UserDisplayName: Flying
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T19:55:36.820Z
Answers.LastActivityDate: 2015-11-06T20:21:17.560Z
Answers.LastEditDate: 2015-11-06T20:21:17.560Z
Answers.UserDisplayName: Andie Hunt
Body: <p>When creating custom fields, and custom field groups, I have fallen into two pit falls.</p>
  
  <p>First, the name of a custom field should not exceed a certain length, causing malfunction in the SQL structure.</p>
  
  <p>Second, values should be unique. Of course, you would say, but look at this example: values: 1,2,3,4,5,6,7,8,9,10,11,12.
  When showing the values in a report, the 2 will show for both 2 and 12, and value 1 will show for 1,10,11 and 12.</p>
  
  <p>The question is, what things should be considered when creating custom fields?</p>
  
Tags: <custom-fields><best-practice>
Title: What should be best practice when creating custom fields?
ThreadText: # What should be best practice when creating custom fields?
  
  (Asked by: username_0 on 2015-03-24)
  
  When creating custom fields, and custom field groups, I have fallen into two pit falls.
  
  First, the name of a custom field should not exceed a certain length, causing malfunction in the SQL structure.
  
  Second, values should be unique. Of course, you would say, but look at this example: values: 1,2,3,4,5,6,7,8,9,10,11,12.
  When showing the values in a report, the 2 will show for both 2 and 12, and value 1 will show for 1,10,11 and 12.
  
  The question is, what things should be considered when creating custom fields?
  
  **Tags:** custom-fields, best-practice
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-03-24. Score: 5 | Accepted answer
  
  If you find yourself wanting to give really long custom field names, think about whether you really should have a fairly short label and then provide help text that goes along with the field.
  
  Besides causing database problems (though CiviCRM largely handles that on its own by just cutting off the field name), you'll have trouble displaying a super-long field name on forms and in reports.
  
  For values, are you actually experiencing this problem? If multiple choices are allowed in a field (let's say all those numbers are available as checkboxes), they're separated by a delimiter character in the database. Searching for 2 won't pull a contact with 12, and searching for 12 won't show results that have both 1 and 2.
  
  In the field itself, the storage is like (not with an asterisk but an unprintable character) "\*1\*2\*6\*" for having 1, 2, and 6 checked. It's stored like "\*11\*12\*" for having 11 and 12 checked. They're easily distinguished.
  
  > **Comments:**
  > **username_0**: Yes I am experiencing this. If I make a multiple choice field, and later on making a report, selecting the option for value 2, I also get included in the result the options for 12  
  > **username_1**: You definitely have a problem in your site.  This isn't supposed to happen. Either there's an issue with your CiviCRM version or a site-specific problem.  One thing to check is your character encoding: maybe your system isn't adding that delimiter character to the saved values or using it to parse them.  
  > **username_4**: Agree, this is behaviour I have not experienced so strongly suspect there is a strange problem on your site. Have you checked the actual values in the option group related to the custom field? You can see them with 'Administer/System Settings/Option Groups'  
  > **username_0**: @AndrewHunt and username_4 Do any of you know if there is a setting somewhere where I should set such a delimiter character for custom multiselect fields?  
  > **username_2**: Try using a numeric list with a leading zero.... ala, 01, 02, 03, .... 09, 10, 11....  
  > **username_3**: The delimiter is actually ASCII control character 001, see https://forum.civicrm.org/index.php%3Ftopic=26395.0.html  
  
  ---
  
  