Answers.Body: <p>That shouldn't be the case... Those tables should have been deleted automatically when you deleted the fields.</p>
  
  <p>Did you actually delete the <strong>fields themselves</strong>? Or did you simply remove them from your section's field layout? Make sure the actual fields were deleted within <strong>Settings > Fields</strong></p>
  
  <hr>
  
  <p>If you're positive those fields have been properly deleted...</p>
  
  <p>Try updating to the latest version of Craft <a href="http://buildwithcraft.com/updates#build2587" rel="nofollow">(v2.2.2587)</a>, which was released today. It includes this bug fix:</p>
  
  <blockquote>
    <p>Retroactively fixed a bug where some Matrix block rows would get left behind in the database when an element was deleted that had a Matrix field.</p>
  </blockquote>
  
  <p>If that doesn't resolve the problem for you, I'd recommend submitting a bug report to Pixel &amp; Tonic. Submit the message via your Dashboard, so you can include a copy of your database and log files.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-25T02:54:30.023Z
Answers.Text: I double checked. The fields are definitely deleted. And I just updated a few minutes ago. The tables are still there. In fact, I have 6 matrix tables "craft_matrixcontent_field_handle" and only 1 matrix field.
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-25T02:59:35.270Z
Answers.Text: I tried creating a new matrix field and then deleting it. The corresponding table was properly created and deleted in the database. Must have been an old bug. Not too worried about it. You think its safe to delete those tables though?
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-25T05:25:24.627Z
Answers.Text: Probably safe... Have all of the corresponding rows in `craft_elements` been removed? Each matrix row contains an `elementId` which is a foreign key to the `id` column of the `craft_elements` table. You'll notice that every matching element is a **MatrixBlock** type. Make sure that any related MatrixBlock element rows are removed first, and those will cascade down to delete their respective matrix rows. Once those are all gone, go ahead and kill the tables.
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-25T05:26:09.023Z
Answers.Text: Oh, and not that it needs to be said, but... **Back up your database before attempting anything like this!**
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-25T05:53:46.950Z
Answers.Text: Thank you. So it looks like only one of the tables has any content in it. And I can see the entries in craft_entries. So I'll delete those first. I then see that I need to delete items from craft_matrixblocks, and craft_matrixblocktypes, then finally the craft_matrixcontent_fieldhandle tables. That sound about right?
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-25T06:18:10.937Z
Answers.Text: I think I see what maybe happened. I converted many of the matrix fields into table fields, rather than deleting them. I suspect that perhaps the system doesn't do any cleanup unless the field is actually deleted. I am a bit confused though... do tables and assets also use craft_matrixblocks and craft_matrixblocktypes (they are a bit similar in some regards)?
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-25T06:29:22.027Z
Answers.Text: Good catch with `craft_matrixblocks` and `craft_matrixblocktypes`. There is probably a "correct" order to delete those various rows, which would take advantage of the **cascade** deletion between related records. But if you don't feel like digging around to find out what cascades into what, then just make sure to be thorough about what you delete. If changing the field type from a matrix to a table doesn't clean up the remaining matrix fields, then that's a bug that should be reported to P&T.
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-25T06:30:38.520Z
Answers.Text: To be honest, I'd really recommend reaching out to P&T directly on this one... They might be aware of something that we're overlooking here. And if this is really a bug stemming from switching your field type, I'd imagine they want to know about that too.
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-25T06:36:28.973Z
Answers.Text: Not a problem, glad to help!
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-10-10T13:09:49.183Z
Answers.Text: Brad (from P&T support) had this recommendation for anyone else attempting this operation: "I think you'd always want to grab the elementId values from the craft_matrixcontent_fieldhandle table and remove those from the craft_elements table. The cascading delete setup on the foreign keys should take care of any remaining Matrix data. Just be sure and make a backup of your db first. :)"
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-23T23:39:25.180Z
Answers.LastActivityDate: 2014-09-23T23:39:25.180Z
Answers.UserDisplayName: Lindsey D
Body: <p>During design/dev I created a bunch of matrix fields that I have since decided not to use. I have deleted the fields, however, I notice that the matrix tables are still in the database. Is it safe to delete these manually, or is there some other cleanup that needs to happen as well (i.e. references within another table, etc.)?</p>
  
  <p><strong>Update:</strong> The problem is caused when changing the fieldtype from a matrix field to another field type, rather than deleting the field altogether, and creating a new one. Even if the field is subsequently deleted, the matrix tables will still remain, which results in orphaned data in the DB. </p>
  
Tags: <matrix><database>
Title: Is it safe to delete unused matrix field tables from the DB?
ThreadText: # Is it safe to delete unused matrix field tables from the DB?
  
  (Asked by: username_0 on 2014-09-23)
  
  During design/dev I created a bunch of matrix fields that I have since decided not to use. I have deleted the fields, however, I notice that the matrix tables are still in the database. Is it safe to delete these manually, or is there some other cleanup that needs to happen as well (i.e. references within another table, etc.)?
  
  **Update:** The problem is caused when changing the fieldtype from a matrix field to another field type, rather than deleting the field altogether, and creating a new one. Even if the field is subsequently deleted, the matrix tables will still remain, which results in orphaned data in the DB.
  
  **Tags:** matrix, database
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-09-23. Score: 2 | Accepted answer
  
  That shouldn't be the case... Those tables should have been deleted automatically when you deleted the fields.
  
  Did you actually delete the **fields themselves**? Or did you simply remove them from your section's field layout? Make sure the actual fields were deleted within **Settings > Fields**
  
  ---
  
  If you're positive those fields have been properly deleted...
  
  Try updating to the latest version of Craft [(v2.2.2587)](http://buildwithcraft.com/updates#build2587), which was released today. It includes this bug fix:
  
  > Retroactively fixed a bug where some Matrix block rows would get left behind in the database when an element was deleted that had a Matrix field.
  
  If that doesn't resolve the problem for you, I'd recommend submitting a bug report to Pixel & Tonic. Submit the message via your Dashboard, so you can include a copy of your database and log files.
  
  > **Comments:**
  > **username_0**: I double checked. The fields are definitely deleted. And I just updated a few minutes ago. The tables are still there. In fact, I have 6 matrix tables "craft_matrixcontent_field_handle" and only 1 matrix field.  
  > **username_0**: I tried creating a new matrix field and then deleting it. The corresponding table was properly created and deleted in the database. Must have been an old bug. Not too worried about it. You think its safe to delete those tables though?  
  > **username_1**: Probably safe... Have all of the corresponding rows in `craft_elements` been removed? Each matrix row contains an `elementId` which is a foreign key to the `id` column of the `craft_elements` table. You'll notice that every matching element is a **MatrixBlock** type. Make sure that any related MatrixBlock element rows are removed first, and those will cascade down to delete their respective matrix rows. Once those are all gone, go ahead and kill the tables.  
  > **username_1**: Oh, and not that it needs to be said, but... **Back up your database before attempting anything like this!**  
  > **username_0**: Thank you. So it looks like only one of the tables has any content in it. And I can see the entries in craft_entries. So I'll delete those first. I then see that I need to delete items from craft_matrixblocks, and craft_matrixblocktypes, then finally the craft_matrixcontent_fieldhandle tables. That sound about right?  
  > **username_0**: I think I see what maybe happened. I converted many of the matrix fields into table fields, rather than deleting them. I suspect that perhaps the system doesn't do any cleanup unless the field is actually deleted. I am a bit confused though... do tables and assets also use craft_matrixblocks and craft_matrixblocktypes (they are a bit similar in some regards)?  
  > **username_1**: Good catch with `craft_matrixblocks` and `craft_matrixblocktypes`. There is probably a "correct" order to delete those various rows, which would take advantage of the **cascade** deletion between related records. But if you don't feel like digging around to find out what cascades into what, then just make sure to be thorough about what you delete. If changing the field type from a matrix to a table doesn't clean up the remaining matrix fields, then that's a bug that should be reported to P&T.  
  > **username_1**: To be honest, I'd really recommend reaching out to P&T directly on this one... They might be aware of something that we're overlooking here. And if this is really a bug stemming from switching your field type, I'd imagine they want to know about that too.  
  > **username_1**: Not a problem, glad to help!  
  > **username_0**: Brad (from P&T support) had this recommendation for anyone else attempting this operation: "I think you'd always want to grab the elementId values from the craft_matrixcontent_fieldhandle table and remove those from the craft_elements table. The cascading delete setup on the foreign keys should take care of any remaining Matrix data. Just be sure and make a backup of your db first. :)"  
  
  ---
  
  