<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>

CC BY-SA 3.0
2018-01-23T13:10:15.397Z
2018-01-23T13:10:15.397Z
andrew.welch
<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>

CC BY-SA 3.0
2018-01-23T00:18:25.070Z
2018-01-23T00:18:25.070Z
Brad Bell
<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>

<matrix><database><field><migration><workflow>
Database: Syncing "craft_fields" table through SQL dumps not possible?
# 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)


---

