Answers.Body: <p>These are defined in MySQL. Adjusting the length of those tables should cover this.</p>
  
  <p>With some data entry, making the changes through the interface can increase the length of the tables in the system.</p>
  
  <p>John</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-08T10:42:45.367Z
Answers.Text: Ok, I did `ALTER TABLE civicrm_contact MODIFY external_identifier VARCHAR(128);` but I still get the error _Value for external_identifier is 67 characters  - This field has a maxlength of 64 characters._
Answers.UserDisplayName: ñull
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-07T06:49:42.170Z
Answers.Text: Yep ditto. needed to import Case Subjects that were > 128 so just altered the VarChar length in db but the import still rejects the longer ones.
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-07T13:19:11.367Z
Answers.Text: Do you have logging turned on, and did you clear caches?
Answers.UserDisplayName: JohnFF
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-26T11:09:36.557Z
Answers.LastActivityDate: 2016-09-26T11:09:36.557Z
Answers.UserDisplayName: JohnFF
Answers.Body: <p>That field is defined at <a href="https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Core/Address.xml#L92" rel="nofollow noreferrer">https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Core/Address.xml#L92</a>. It is run through GenCode.php to create the definition of the field and table used in the database installation. This also creates the definition in DAO file (CRM/Core/DAO/Address.php):</p>
  
  <pre><code>'street_address' =&gt; array(
        'name' =&gt; 'street_address',
        'type' =&gt; CRM_Utils_Type::T_STRING,
        'title' =&gt; ts('Street Address') ,
        'description' =&gt; 'Concatenation of all routable street address components (prefix, street number, street name, suffix, unit
    number OR P.O. Box). Apps should be able to determine physical location with this data (for mapping, mail
    delivery, etc.).
  ',
        'maxlength' =&gt; 96,
        'size' =&gt; CRM_Utils_Type::HUGE,
        'import' =&gt; true,
        'where' =&gt; 'civicrm_address.street_address',
        'headerPattern' =&gt; '/(street|address)/i',
        'dataPattern' =&gt; '/^(\d{1,5}( [0-9A-Za-z]+)+)$|^(P\.?O\.\? Box \d{1,5})$/i',
        'export' =&gt; true,
        'table_name' =&gt; 'civicrm_address',
        'entity' =&gt; 'Address',
        'bao' =&gt; 'CRM_Core_BAO_Address',
        'html' =&gt; array(
          'type' =&gt; 'Text',
        ) ,
  </code></pre>
  
  <p>I bet that the generic import code truncates varchars to the maxlength of the field. So you could override this file to change that behaviour.</p>
  
  <p>FWIW, on a buildkit development site you can set things up to re-run the GenCode so that change the xml for schema will be reflected in the regenerated DAO file.</p>
  
  <p>If you want to propose a change to the schema in core, you will need to include in the PR an ALTER TABLE query in the appropriate file for the release in <a href="https://github.com/civicrm/civicrm-core/tree/master/CRM/Upgrade/Incremental/sql" rel="nofollow noreferrer">https://github.com/civicrm/civicrm-core/tree/master/CRM/Upgrade/Incremental/sql</a>, eg 4.7.28.mysql.tpl. Increasing the field length doesn't involve loss of data or any need to convert the existing data, so it would be a straightforward change. </p>
  
  <p>However, I'm not sure whether proposing a change to a field that has been unchanged since version 1.1 will get the community approval ideally required for a schema change. FWIW, I'm mildly supportive and this has caused us grief over the years. I'd also try to review what impact a longer field might have on layout onscreen, in address labels in core, and in html message templates, etc.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-12T15:16:28.597Z
Answers.LastActivityDate: 2017-10-12T15:16:28.597Z
Answers.UserDisplayName: Joe Murray
Body: <p>I need to import addresses using the API. Some addresses go over the CiviCRM limit. For instance street_address has a limit of 96 characters. I would like to know where are these limits defined in CiviCRM or where are they documented? I don't want to use the trial and error method to find out. </p>
  
Tags: <developer><fields><documentation>
Title: Where can I find the field string length?
ThreadText: # Where can I find the field string length?
  
  (Asked by: username_0 on 2016-09-26)
  
  I need to import addresses using the API. Some addresses go over the CiviCRM limit. For instance street\_address has a limit of 96 characters. I would like to know where are these limits defined in CiviCRM or where are they documented? I don't want to use the trial and error method to find out.
  
  **Tags:** developer, fields, documentation
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2016-09-26. Score: 1
  
  These are defined in MySQL. Adjusting the length of those tables should cover this.
  
  With some data entry, making the changes through the interface can increase the length of the tables in the system.
  
  John
  
  > **Comments:**
  > **username_0**: Ok, I did `ALTER TABLE civicrm_contact MODIFY external_identifier VARCHAR(128);` but I still get the error _Value for external_identifier is 67 characters  - This field has a maxlength of 64 characters._  
  > **username_2**: Yep ditto. needed to import Case Subjects that were > 128 so just altered the VarChar length in db but the import still rejects the longer ones.  
  > **username_1**: Do you have logging turned on, and did you clear caches?  
  
  ---
  
  ### Answer by username_3 on 2017-10-12. Score: 1
  
  That field is defined at <https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Core/Address.xml#L92>. It is run through GenCode.php to create the definition of the field and table used in the database installation. This also creates the definition in DAO file (CRM/Core/DAO/Address.php):
  
  ```
  'street_address' => array(
        'name' => 'street_address',
        'type' => CRM_Utils_Type::T_STRING,
        'title' => ts('Street Address') ,
        'description' => 'Concatenation of all routable street address components (prefix, street number, street name, suffix, unit
    number OR P.O. Box). Apps should be able to determine physical location with this data (for mapping, mail
    delivery, etc.).
  ',
        'maxlength' => 96,
        'size' => CRM_Utils_Type::HUGE,
        'import' => true,
        'where' => 'civicrm_address.street_address',
        'headerPattern' => '/(street|address)/i',
        'dataPattern' => '/^(\d{1,5}( [0-9A-Za-z]+)+)$|^(P\.?O\.\? Box \d{1,5})$/i',
        'export' => true,
        'table_name' => 'civicrm_address',
        'entity' => 'Address',
        'bao' => 'CRM_Core_BAO_Address',
        'html' => array(
          'type' => 'Text',
        ) ,
  
  ```
  
  I bet that the generic import code truncates varchars to the maxlength of the field. So you could override this file to change that behaviour.
  
  FWIW, on a buildkit development site you can set things up to re-run the GenCode so that change the xml for schema will be reflected in the regenerated DAO file.
  
  If you want to propose a change to the schema in core, you will need to include in the PR an ALTER TABLE query in the appropriate file for the release in <https://github.com/civicrm/civicrm-core/tree/master/CRM/Upgrade/Incremental/sql>, eg 4.7.28.mysql.tpl. Increasing the field length doesn't involve loss of data or any need to convert the existing data, so it would be a straightforward change.
  
  However, I'm not sure whether proposing a change to a field that has been unchanged since version 1.1 will get the community approval ideally required for a schema change. FWIW, I'm mildly supportive and this has caused us grief over the years. I'd also try to review what impact a longer field might have on layout onscreen, in address labels in core, and in html message templates, etc.
  
  
  ---
  
  