1364 Field 'XXX' doesn't have a default value Experienced all over the site

Hey all!!

I have tried to search for an answer but the problems aren't quite what I am experiencing...

when I tried to log into admin, I get this error

1364 Field 'log_id' doesn't have a default value
in:
[insert into zen_admin_activity_log (access_date, admin_id, page_accessed, page_parameters, ip_address) values (now(), '0', 'login.php ', '', '65.95.237.19')]
If you were entering information, press the BACK button in your browser and re-check the information you had entered to be sure you left no blank fields. 


I also tried to browse my website and place an order and got this error

1364 Field 'customers_basket_id' doesn't have a default value
in:
[insert into zen_customers_basket (customers_id, products_id, customers_basket_quantity, customers_basket_date_added) values ('1', '3475', '1', '20190108')] 

What version of Zen Cart are you using?
It's pretty old and I can't log into the admin to check but I think it's 1.3.9....

Has your site been upgraded? When? From what version(s)?
While the Live DB wasn't touched, I did make a dummy DB to install a copy of the website to install templates and test it out before upgrading on the live site/DB. I tried out the 1.5.5 version on the dummy DB

**What plugins/addons have you installed? **
Just created a new DB, tried to dump a copy of live db to it for testing, installed a template Tableau

What version of PHP and MySQL is your server using? (See Admin->Tools->Server Info)
I can't login to see this.

WHEN did the problem "start"? How does that compare with other events of your hosting company, changes you've made to your site files/addons, or your admin settings, etc?
It started today... yesterday was the time last I got an order and last time I was able to log in.

Please post the contents of related "debug logs" generated by Zen Cart (wrap the content in [code]).
Where can I find this?

Please post your site URL so we can take a look at it. This is especially important if you're encountering display/layout problems, so the problem can be seen directly.*

www.the litt lest giftbou tique.com

Thanks in advance for reading!

Doing some digging, I have no idea if this is at all related to my problem..

https://stackoverflow.com/questions/15438840/mysql-error-1364-field-doesnt-have-a-default-values

dimsumgurl:

Doing some digging, I have no idea if this is at all related to my problem..

https://stackoverflow.com/questions/15438840/mysql-error-1364-field-doesnt-have-a-default-values
Yes it's related, but doesn't contain the full solution to your problem.

The issue is that the PHP code in your old version of Zen Cart contains SQL queries that are trying to put data into the database, but either don't list all the related fields and are relying on defaults, but the database itself doesn't contain a default value for unlisted fields.
That's a bunch of tech jargon to most people.

The real issue is two-fold:

1. Your hosting company has probably "suddenly" upgraded their MySQL software to a newer version that enforces a "strict mode" that requires tables to be defined with default values when not specified in SQL queries.
   This "sudden" new strict mode is what's causing the "sudden" break.

2. Newer versions of Zen Cart contain 2 important updates to accommodate this: updated SQL queries in the PHP code, and database updates to define the missing defaults. At least as far as built-in functionality goes (can't speak for plugins that have their own SQL fields etc).

Your long-term fix is to complete an upgrade.

The short-term fix is to disable strict-mode.
The correct "how" to do this depends on your current Zen Cart version. What's the contents of your /includes/version .php file?

Hey Dr Byte,

Thanks for the reply.

I asked my hosting about that and they said they didn't do any updates on MySQL versions... BUT

Luckily since I have a copy of the database installed on a dummy DB i was able to compare and see what the differences were, why I could access the dummy fine but issues on the live..

I went into MYphp Admin and looked for the admin_log on the live one and noticed that log_id, AUTO_INCREMENTS wasn't checked off like my dummy DB was. so I checked it, and now I can log in.

I haven't repeated this for the customer log in issue yet.... but it makes me think "where else is having this issue?"

I checked contents of my /includes/version .php file

define('PROJECT_VERSION_NAME', 'Zen Cart');
define('PROJECT_VERSION_MAJOR', '1');
define('PROJECT_VERSION_MINOR', '3.9h');

DrByte:

The real issue is two-fold:

1. Your hosting company has probably "suddenly" upgraded their MySQL software to a newer version that enforces a "strict mode" that requires tables to be defined with default values when not specified in SQL queries.
   This "sudden" new strict mode is what's causing the "sudden" break.

Besides the log_id having issues that neew seem to be fixed.. I am trying to do the same for customers_basket_id

But when I try to check box AUTO_INCREMENTS, I get this error

#1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key

I also noticed that under phpmyadmin under zen_customers_basket, there is normally both columns and indexes. Now index isn't not there anymore...

What to do? Is upgrade now the only option?

Thanks for reading and helping!

I am now starting to back track on what could have gone wrong and feel the worst might have happened...

When I backed up the DB, I followed the instructions here specifically remembering that I checked Add AUTO_INCREMENT value

https://www.zen-cart.com/content.php?144

But when I went into the SQL file.... that is not the case...

DROP TABLE IF EXISTS `zen_admin_activity_log`;
CREATE TABLE `zen_admin_activity_log` (
  `log_id` int(15) NOT NULL,
  `access_date` datetime NOT NULL DEFAULT '0001-01-01 00:00:00',
  `admin_id` int(11) NOT NULL DEFAULT '0',
  `page_accessed` varchar(80) NOT NULL DEFAULT '',
  `page_parameters` text,
  `ip_address` varchar(15) NOT NULL DEFAULT ''
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Now how does this factor in the issue?

Well remember I mentioned that I created a new DB to test the upgrade before implementing it on the live? FOR SOME REASON. I EVEN triple checked this BEFORE I imported, I have a bad feeling FOR SOME REASON the back up was imported to the LIVE DB. I triple checked that the name of the dummy DB was selected before I clicked to import.

But based on what I've investigated... I have a bad feeling somehow the improper back up of the live DB was re-imported and now is a bit broken in areas that's supposed to have auto_increments but doesn't anymore because of the bad DB back up that didn't have that in it.

Now Im wondering... what can I do? Take an even older SQL back up and compare the differences and add those into the newest backup and import that again? Or what....... Or go through the differences and go into phpmyadmin and reactivae the auto_increments in the IDs that's missing them?

I am lost on what's the next best move based on my assumptions of what happened here.

Thanks

Here's my thoughts. If your backup online is good and functional and it's just the current live site that is the problem, then:
Put the site in maintenance mode.
Export your live site in its entirety.
Export your backup of just the table structure.
Open your favorite software comparison tool.
Line up the table structure for both files.
Copy the table structure (without the new index number of the backup) from the backup to the live site.
Re-upload/import the new file to your live site.
Test the live site.
Put the live site back in service once good.

mc12345678:

Here's my thoughts. If your backup online is good and functional and it's just the current live site that is the problem, then:
Put the site in maintenance mode.
Export your live site in its entirety.
Export your backup of just the table structure.
Open your favorite software comparison tool.
Line up the table structure for both files.
Copy the table structure (without the new index number of the backup) from the backup to the live site.
Re-upload/import the new file to your live site.
Test the live site.
Put the live site back in service once good.

Ah! Thank you for this tip! So I should do all this before upgrading right? It would be a bad idea to upgrade now which some IDs not on auto_increment?

Thank you!!