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 (2.7.0.4846)
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/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:2:970326
at tryCatch (/Applications/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:8:2180690)
at Generator._invoke (/Applications/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:8:2180313)
at Generator.next (/Applications/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:8:2181465)
at asyncGeneratorStep (/Applications/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:2:1003)
at _next (/Applications/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:2:1302)
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/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:2:970326
at tryCatch (/Applications/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:8:2180690)
at Generator._invoke (/Applications/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:8:2180313)
at Generator.next (/Applications/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:8:2181465)
at asyncGeneratorStep (/Applications/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:2:1003)
at _next (/Applications/DevKinsta.app/Contents/Resources/app.asar/main.prod.js:2:1302)
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.
Navigate to your pulled files with this terminal command: cd public/YOURSITENAME
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.com' '//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!
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.
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.
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.
