DK0066 Failed to import database dump

Q: Date/Time this occurred (Provide your time zone also)
A: 2022-08-22 22:33 CET at the latest

Q: DevKinsta Version
A: Version 2.7.0 (

Q: OS Version
**A: MacOS 12.5 (M1 Pro) **

Q: Docker Desktop Version
A: 4.11.1

Q: Were any error codes or messages observed? If so, what were they?
A: DK0066

Q: Detailed Description of the Problem
A: [2022-08-22 22:32:56.524] [info] [containerExec] Command 'mysql -h devkinsta_db -u root -p**** Ksebe < “/www/kinsta/public/ksebe/backup.sql”’ on devkinsta_fpm finished with exit code 1
[2022-08-22 22:32:56.527] [error] Error - DK0066: IMPORT_DB_DUMP: Error (1): SERROR 1146 (42S02) at line 6710: Table ‘ksebe.v_recon_appointments’ doesn’t exist
at /Applications/
at tryCatch (/Applications/
at Generator._invoke (/Applications/
at (/Applications/
at asyncGeneratorStep (/Applications/
at _next (/Applications/
at runMicrotasks ()
at processTicksAndRejections (node:internal/process/task_queues:96:5)
[2022-08-22 22:32:56.552] [error] [ipcMainStep] Error in operation SITE_CREATION, step rsync: Error - DK0066: IMPORT_DB_DUMP: Error (1): SERROR 1146 (42S02) at line 6710: Table ‘ksebe.v_recon_appointments’ doesn’t exist
at /Applications/
at tryCatch (/Applications/
at Generator._invoke (/Applications/
at (/Applications/
at asyncGeneratorStep (/Applications/
at _next (/Applications/
at runMicrotasks ()
at processTicksAndRejections (node:internal/process/task_queues:96:5)

However, when checking with the kinsta team, they are able to re-import the SQL dump - and “select * from ksebe.v_recon_appointments limit 10;” also returns values without issue, so the view exists.

Any ideas what might be wrong here? Already tried reinstalling dev kinsta and deleting the containers before re-attempting the site pull.**

Hi @pavol, thanks for reaching out. Could you try this for me:

  • Please create a Staging Environment then try to pull that with DevKinsta. Do you still get the same error?

  • In Staging, please SSH and try to run the command wp db import backup.sql from your ~/public directory. Does that work without issue? That’s basically the command that DevKinsta is using.

  • Another test would be to create a blank WP site within DevKinsta then Sync that site with your Live/Staging website. If the DB import fails again then try only Syncing only files. Your synced files will contain the database SQL file which you can then try to import manually using the Database Manager. That might work differently or give you a better clue as to what’s happening.

  1. image
  2. image

Please let us know if you run into issues with these tests!

Hi @Kevin,

thanks for the super quick reply! These are the test results:

  1. Pulling staging environment results in the same issue as pulling live env (DK0066, issue with the same table)
  2. wp db import backup.sql works with no issues when ran SSH-ed into Staging
  3. When following the approach with blank site, I got the following:

Any pointers from this would be super helpful! :slight_smile:


Very strange, I’ve never seen a memory error with Adminer!
Okay, lets see if using wp-cli locally works as well:

  1. I’m assuming you’re using Docker Desktop but please let me know if you aren’t. Open Docker, go to “Containers” and open a terminal for devkinsta_fpm
  2. Navigate to your pulled files with this terminal command: cd public/YOURSITENAME
  3. Now try this wp-cli command: wp db import backup.sql --allow-root

Does that complete without issue? If it does, you can use wp-cli to manually do your search and replace:
wp search-replace '//' '//example.local' --allow-root

I’m still not sure what’s special about that view/table that’s causing that error. I think it’s more of an SQL issue but I’m definitely keeping an eye out for similar issues.

Please let me know what sort of results you have with the above approach or if you need any clarification!

Hey @Kevin,

just tried what you proposed, and it did not work. Looking at the backup.sql, the issue seems to be that the views that I’m using are extracted in alphabetical order into the backup.sql (???), and then the creation doesn’t work, since I’m using a couple of views to create the “final” one a couple of times around.

Tried deleting all the view creations from backup.sql, and then wp db import worked - as a workaround, this is OK, but probably not the best behavior in general…

Thanks for the update @pavol.
I’ll bring this up with our developers/try to reproduce it as well. It seems like a mysqldump issue that hopefully has a solution.

I’m wondering why importing the same DB works on Staging but not on Local/DevKinsta if View order is the issue.

Honestly, @Kevin, me too :smiley:

Hi @pavol, so I did some basic testing with two views. The order of the individual views didn’t seem to matter when they referenced one another, however your views seem more complex. How exactly do you create that “Final view?” Basically if you can ever create a similar issue with Views that reference default WordPress tables on test/fresh install, we would be able to reproduce/test on our end.

One issue I immediately had was that my views didn’t immediately work because of this issue: permissions - MySQL error 1449: The user specified as a definer does not exist - Stack Overflow . I quickly fixed that by creating the appropriate user using an SQL command. I wonder if that could any way be related to what you are experiencing.

That being the issue would explain why you don’t see issues on Live/Staging since the user that created the views already exists there unlike in DK/local. But that’s really a guess since I can’t reproduce this on my end yet.