Answers.Body: <p>You might want to develop a workflow where you have one database (usually <code>live</code> production or <code>staging</code>) where all changes are made, and then sync down the database/assets from there.</p>
  
  <p>Adding this concept of which server is the "source of truth" will greatly simplify keeping things in sync.</p>
  
  <p><a href="https://github.com/nystudio107/craft-scripts" rel="nofollow noreferrer">Craft-Scripts</a> are a collection of shell scripts that help you do just that. All of this is discussed in detail in the article <a href="https://nystudio107.com/blog/database-asset-syncing-between-environments-in-craft-cms" rel="nofollow noreferrer">Database &amp; Asset Syncing Between Environments in Craft CMS</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-23T13:10:15.397Z
Answers.LastActivityDate: 2018-01-23T13:10:15.397Z
Answers.UserDisplayName: andrew.welch
Answers.Body: <blockquote>
    <p>Manually adding fields in both CPs is very prone to errors …</p>
  </blockquote>
  
  <p>Yes, but probably less error prone that the method you're doing now. :)</p>
  
  <p>Field information is stored in more than the <code>craft_fields</code> table.  For example, most field content is saved in <code>craft_content</code>, but Matrix fields get their entire own tables to store Matrix content, which has dynamic rows and columns based on Matrix field settings and Matrix data.</p>
  
  <p>But even then <code>craft_matrixblocks</code> and <code>craft_matrixblocktypes</code> might change depending on what has been done.  And data might have been added to <code>craft_relations</code> if the Matrix field had any relational fields in it (Users, Entries, Assets, Categories, etc.).</p>
  
  <p>It's a complicated problem (moving schema and data changes in Craft between environments) that <a href="https://craftcms.com/news/craft-3-content-migrations" rel="nofollow noreferrer">Content Migrations</a> in the upcoming Craft 3 takes a baby step towards solving and one we hope to address long-term in the future.</p>
  
  <p>Some further reading: <a href="https://craftcms.stackexchange.com/questions/10/whats-the-best-practice-for-handling-data-migration-and-organization-across-dev/15#15">What&#39;s the best practice for handling data migration and organization across development environments?</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-23T00:18:25.070Z
Answers.LastActivityDate: 2018-01-23T00:18:25.070Z
Answers.UserDisplayName: Brad Bell
Body: <p>I've been trying to simply sync an addition to a matrix field building block from my local dev server to the live environment database by doing a SQL dump of the "craft_fields" table. I now have the same entry appearing in the remote database, however in the CP fields setup the additional field is not showing up in that particular matrix field. </p>
  
  <p>What am I doing wrong? Or in other words: How can I optimize the workflow without having to do everything twice, in each CP (dev/live), for each field added later in the project's process? </p>
  
  <p>Manually adding fields in both CPs is very prone to errors …</p>
  
Tags: <matrix><database><field><migration><workflow>
Title: Database: Syncing "craft_fields" table through SQL dumps not possible?
ThreadText: # Database: Syncing "craft_fields" table through SQL dumps not possible?
  
  (Asked by: username_0 on 2018-01-22)
  
  I've been trying to simply sync an addition to a matrix field building block from my local dev server to the live environment database by doing a SQL dump of the "craft\_fields" table. I now have the same entry appearing in the remote database, however in the CP fields setup the additional field is not showing up in that particular matrix field.
  
  What am I doing wrong? Or in other words: How can I optimize the workflow without having to do everything twice, in each CP (dev/live), for each field added later in the project's process?
  
  Manually adding fields in both CPs is very prone to errors …
  
  **Tags:** matrix, database, field, migration, workflow
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-01-23. Score: 2 | Accepted answer
  
  You might want to develop a workflow where you have one database (usually `live` production or `staging`) where all changes are made, and then sync down the database/assets from there.
  
  Adding this concept of which server is the "source of truth" will greatly simplify keeping things in sync.
  
  [Craft-Scripts](https://github.com/nystudio107/craft-scripts) are a collection of shell scripts that help you do just that. All of this is discussed in detail in the article [Database & Asset Syncing Between Environments in Craft CMS](https://nystudio107.com/blog/database-asset-syncing-between-environments-in-craft-cms)
  
  
  ---
  
  ### Answer by username_2 on 2018-01-23. Score: 1
  
  > Manually adding fields in both CPs is very prone to errors …
  
  Yes, but probably less error prone that the method you're doing now. :)
  
  Field information is stored in more than the `craft_fields` table. For example, most field content is saved in `craft_content`, but Matrix fields get their entire own tables to store Matrix content, which has dynamic rows and columns based on Matrix field settings and Matrix data.
  
  But even then `craft_matrixblocks` and `craft_matrixblocktypes` might change depending on what has been done. And data might have been added to `craft_relations` if the Matrix field had any relational fields in it (Users, Entries, Assets, Categories, etc.).
  
  It's a complicated problem (moving schema and data changes in Craft between environments) that [Content Migrations](https://craftcms.com/news/craft-3-content-migrations) in the upcoming Craft 3 takes a baby step towards solving and one we hope to address long-term in the future.
  
  Some further reading: [What's the best practice for handling data migration and organization across development environments?](https://craftcms.stackexchange.com/questions/10/whats-the-best-practice-for-handling-data-migration-and-organization-across-dev/15#15)
  
  
  ---
  
  