Restore db is giving error Uncaught TypeError: Argument 1 passed to Mage_Core_Model_Store::setWebsite() must be an instance of Mage_Core_Model_Website, null given

[f1-outsourcing]

I have an almost standard db, no modules adding columns etc. When I drop it and read back a mysql dump (with disabling key checks) I am getting this error, removed also the cache stuff in ./var/ ./tmp

PHP Fatal error: Uncaught TypeError: Argument 1 passed to Mage_Core_Model_Store::setWebsite() must be an instance of Mage_Core_Model_Website, null given, called in x/app/code/core/Mage/Core/Model/App.php on line 661 and defined in x/app/code/core/Mage/Core/Model/Store.php:461\nStack trace:\n#0 x/app/code/core/Mage/Core/Model/App.php(661): Mage_Core_Model_Store->setWebsite(NULL)\n#1 x/app/code/core/Mage/Core/Model/App.php(493): Mage_Core_Model_App->_initStores()\n#2 x/app/code/core/Mage/Core/Model/App.php(301): Mage_Core_Model_App->_initCurrentStore('admin', 'store')\n#3 x/app/Mage.php(677): Mage_Core_Model_App->init('admin', 'store', Array)\n#4 x/cron.php(44): Mage::app('admin')\n#5 {main}...\n'

[f1-outsourcing]

wtf the dump file has this statement in it

INSERT INTO core_store VALUES (0,'admin',0,0,'Admin',0,1)
While after the import, the table id is not 0 but 4????

[addison74]

To get answers, try to describe all the steps you take. The way you exposed the issue is extremely obvious. What you're doing there is hard for me to believe would be an issue in OpenMage code. If you did a correct SQL dump, then dropped the database and created a new one and import the SQL dump, all steps in the Terminal it can't work. I think I did this thing hundreds of times without any errors, especially when the database cracked. Try to avoid using phpMyAdmin for Magento databases. A few tables is OK but not for over 300 with tons of data.

[f1-outsourcing]

This seems to be an issue with mysql. If you have a dump file that seems to have the correct data, and the import is different (using mysql databaseane -p < file.sql )
But that would mean that you can never restore a mysqldump, which is just totally ridiculous.

[f1-outsourcing]

To get answers, try to describe all the steps you take. The way you exposed the issue is extremely obvious. What you're doing there is hard for me to believe would be an issue in OpenMage code. If you did a correct SQL dump, then dropped the database and created a new one and import the SQL dump, all steps in the Terminal it can't work. I think I did this thing hundreds of times without any errors, especially when the database cracked. Try to avoid using phpMyAdmin for Magento databases. A few tables is OK but not for over 300 with tons of data.

Mysql is by default(?) converting all inserted rows with a '0' with an increment value. Thus you have to set SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO"; on importing the dump. I think this 'weird' behaviour should be documented everywhere, because nobody will be expecting this. Makes me also wonder what 'other' data is changed by a an import.

NO_AUTO_VALUE_ON_ZERO affects handling of AUTO_INCREMENT columns. Normally, you generate the next sequence number for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the next sequence number.

https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html

[luigifab]

When you do make database dump, use something like this:
mysqldump --default-character-set=utf8mb4 --single-transaction -u USER -p DBNAME > db.sql

Do not use PhpMyAdmin, this is a enemy of your data.

[f1-outsourcing]

I am always using the cli dump of mysql. The dump file was ok, because the sql file had the correct id's.

It is quite unbelievable but the developers of mysql implement this design:

"you generate the next sequence number for the column by inserting either NULL or 0 into it".

I think lots of people are having this issue, because I searched quite a lot on it and found allways solutions referring to correcting the id back to 0. So I wondered why my Id from the dump file was not 0 anymore but 4. I even put the table as a first in the dump file and still I had this change. Then I just created the table from the cli and imported data and again the change from 0 to 4. It is just ridiculous someone implements such behaviour. How many mysql db do not have increment fields that store 0 id's.

I am glad I use postgres for my own stuff. Mysql was and always will be an amateur db.