Answers.Body: <p>The fact that the record displays correctly on save suggests that there's a difference between how correct and incorrect values are recorded in the MySQL database.  I've seen this happen on multi-select custom fields when you import values with a comma rather than a <a href="https://forum.civicrm.org/index.php%3Ftopic=36179.0.html" rel="nofollow noreferrer">value separator</a>.  The field LOOKS ok, but it's not stored correctly - but on save, the form corrects the data.</p>
  
  <p>If you view the underlying MySQL table in a tool that supports showing hidden characters, I'm guessing you'll find one missing (or present) in the incorrect records.</p>
  
  <p>UPDATE: To see if you can view hidden characters, try inserting one into the database.  E.g.:
  <code>INSERT INTO civicrm_worldregion (name) SELECT CONCAT('a', UNHEX(01), 'b');
  </code></p>
  
  <p>If I view that in the MySQL CLI client, I can't see it:
  <code>
  mysql&gt; SELECT name FROM civicrm_worldregion ORDER BY id DESC LIMIT 1;
  +------+
  | name |
  +------+
  | ab  |
  +------+
  1 row in set (0.00 sec)
  </code></p>
  
  <p>I also can't see it from my command line:</p>
  
  <p><code>~/ » mysql temp -e 'SELECT name FROM civicrm_worldregion ORDER BY id DESC LIMIT 1'
  +------+
  | name |
  +------+
  | ab  |
  +------+
  </code></p>
  
  <p>However, if I pipe to <code>vim</code> then it appears as:
  <code>
  name
  c^Ab
  </code></p>
  
  <p>That <code>^A</code> is in blue, which indicates it's not actually "caret then A" but rather "control character 0x01".</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-05T18:47:07.613Z
Answers.Text: Jon G - I can see how this might produce the behaviour I have seen, but I think the particular field is f
Answers.UserDisplayName: Mick Kahn
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-05T18:53:29.253Z
Answers.Text: hit return too early and couldn't edit... Jon G - I can see how this might produce the behaviour I have seen, but I think the particular field is filled in by the code and not by the user. around line 1302 in membership.php looks right to me. So I can't see how that would sometimes be right but sometimes wrong. I'm not expert in viewing MySQL - will phpMyAdmin show the hidden characters? But I realise I can't test this at present because I have corrected all the ones that were not showing. I will have to wait until they appear again.
Answers.UserDisplayName: Mick Kahn
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-06T22:39:55.663Z
Answers.Text: I agree that my scenario is different than yours because the code is producing the value for you - and that suggests a bug if you can nail this down.  Can you restore a backup to a temporary database?  I don't think PhpMyAdmin can view hidden characters - the best way to find out is to insert a hidden character into a record and see if it looks different!  I'll update my answer to explain the technique.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-07T14:38:49.920Z
Answers.Text: Thanks - I'm not sure I can restore the backup as I'd need to do some testing be able to not overwrite the live site and don't know if I have time before the backup expires (its a hosted service so can't just save it for later). I should not have corrected all the errors and left one for testing.
Answers.UserDisplayName: Mick Kahn
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-04T17:38:19.047Z
Answers.LastActivityDate: 2018-11-06T22:44:18.310Z
Answers.LastEditDate: 2018-11-06T22:44:18.310Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>When doing a find or an export,  the 'source' fields for memberships is blank for some records. For the records where it displays, its obviously been populated automatically when the membership is set up offline. For the records where it is blank, if I view the record, the value is there and is the same automatically created values as the ones that did display. If I edit and then save without making any changes, then that membership behaves as it should.</p>
  
  <p>I'm using CiviCRM 4.7.24 but can't see anything in subsequent release notes that relates. It would be difficult to try on the demo system because most of the registrations come through correctly.</p>
  
Tags: <civimember>
Title: membership source field not displaying in reports or exports sometimes
ThreadText: # membership source field not displaying in reports or exports sometimes
  
  (Asked by: username_0 on 2018-11-03)
  
  When doing a find or an export, the 'source' fields for memberships is blank for some records. For the records where it displays, its obviously been populated automatically when the membership is set up offline. For the records where it is blank, if I view the record, the value is there and is the same automatically created values as the ones that did display. If I edit and then save without making any changes, then that membership behaves as it should.
  
  I'm using CiviCRM 4.7.24 but can't see anything in subsequent release notes that relates. It would be difficult to try on the demo system because most of the registrations come through correctly.
  
  **Tags:** civimember
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-11-04. Score: 1
  
  The fact that the record displays correctly on save suggests that there's a difference between how correct and incorrect values are recorded in the MySQL database. I've seen this happen on multi-select custom fields when you import values with a comma rather than a [value separator](https://forum.civicrm.org/index.php%3Ftopic=36179.0.html). The field LOOKS ok, but it's not stored correctly - but on save, the form corrects the data.
  
  If you view the underlying MySQL table in a tool that supports showing hidden characters, I'm guessing you'll find one missing (or present) in the incorrect records.
  
  UPDATE: To see if you can view hidden characters, try inserting one into the database. E.g.:
  `INSERT INTO civicrm_worldregion (name) SELECT CONCAT('a', UNHEX(01), 'b');`
  
  If I view that in the MySQL CLI client, I can't see it:
  `mysql> SELECT name FROM civicrm_worldregion ORDER BY id DESC LIMIT 1;
  +------+
  | name |
  +------+
  | ab |
  +------+
  1 row in set (0.00 sec)`
  
  I also can't see it from my command line:
  
  `~/ » mysql temp -e 'SELECT name FROM civicrm_worldregion ORDER BY id DESC LIMIT 1'
  +------+
  | name |
  +------+
  | ab |
  +------+`
  
  However, if I pipe to `vim` then it appears as:
  `name
  c^Ab`
  
  That `^A` is in blue, which indicates it's not actually "caret then A" but rather "control character 0x01".
  
  > **Comments:**
  > **username_0**: Jon G - I can see how this might produce the behaviour I have seen, but I think the particular field is f  
  > **username_0**: hit return too early and couldn't edit... Jon G - I can see how this might produce the behaviour I have seen, but I think the particular field is filled in by the code and not by the user. around line 1302 in membership.php looks right to me. So I can't see how that would sometimes be right but sometimes wrong. I'm not expert in viewing MySQL - will phpMyAdmin show the hidden characters? But I realise I can't test this at present because I have corrected all the ones that were not showing. I will have to wait until they appear again.  
  > **username_1**: I agree that my scenario is different than yours because the code is producing the value for you - and that suggests a bug if you can nail this down.  Can you restore a backup to a temporary database?  I don't think PhpMyAdmin can view hidden characters - the best way to find out is to insert a hidden character into a record and see if it looks different!  I'll update my answer to explain the technique.  
  > **username_0**: Thanks - I'm not sure I can restore the backup as I'd need to do some testing be able to not overwrite the live site and don't know if I have time before the backup expires (its a hosted service so can't just save it for later). I should not have corrected all the errors and left one for testing.  
  
  ---
  
  