Fatal error: 1048:Column 'value' cannot be null :: insert into sessions (sesskey, ex

[Website Rob]

Here is more info to go by.

Apache 2.4
MySQL 5.6 - Mode: STRICT_TRANS_TABLES, NO_ENGINE_SUBSTITUTION
PHP 5.6.29
Zen Cart 1.5.5

[07-Jan-2017 23:05:19 America/Denver] Request URI: /***-c-24/***-c-24_29/***-p-371.html, IP address: ***
#1  trigger_error() called at [/***/***/public_html/includes/classes/db/mysql/query_factory.php:167]
#2  queryFactory->show_error() called at [/***/***/public_html/includes/classes/db/mysql/query_factory.php:139]
#3  queryFactory->set_error() called at [/***/***/public_html/includes/classes/db/mysql/query_factory.php:266]
#4  queryFactory->Execute() called at [/***/***/public_html/includes/functions/sessions.php:69]
#5  _sess_write()
#6  session_write_close() called at [/***/***/public_html/includes/application_bottom.php:16]
#7  require(/***/***/public_html/includes/application_bottom.php) called at [/***/***/public_html/index.php:105]

[07-Jan-2017 23:05:19 America/Denver] PHP Fatal error:  1048:Column 'value' cannot be null :: insert into zen_sessions (sesskey, expiry, `value`)
            values ('469db6ea8476d9b0150fc3551463e107', 1483856959, null)
            ON DUPLICATE KEY UPDATE `value`=null, expiry=1483856959 ==> (as called by) /***/***/public_html/includes/functions/sessions.php on line 69 <== in /***/***/public_html/includes/classes/db/mysql/query_factory.php on line 167

Although I do believe the above are default files, I'd like to mention that Dual Pricing module has been installed. Not sure which version exactly and it has been modified a bit by other coders.

[mc12345678]

Here is more info to go by.

Apache 2.4
MySQL 5.6 - Mode: STRICT_TRANS_TABLES, NO_ENGINE_SUBSTITUTION
PHP 5.6.29
Zen Cart 1.5.5

[07-Jan-2017 23:05:19 America/Denver] Request URI: /***-c-24/***-c-24_29/***-p-371.html, IP address: ***
#1  trigger_error() called at [/***/***/public_html/includes/classes/db/mysql/query_factory.php:167]
#2  queryFactory->show_error() called at [/***/***/public_html/includes/classes/db/mysql/query_factory.php:139]
#3  queryFactory->set_error() called at [/***/***/public_html/includes/classes/db/mysql/query_factory.php:266]
#4  queryFactory->Execute() called at [/***/***/public_html/includes/functions/sessions.php:69]
#5  _sess_write()
#6  session_write_close() called at [/***/***/public_html/includes/application_bottom.php:16]
#7  require(/***/***/public_html/includes/application_bottom.php) called at [/***/***/public_html/index.php:105]

[07-Jan-2017 23:05:19 America/Denver] PHP Fatal error:  1048:Column 'value' cannot be null :: insert into zen_sessions (sesskey, expiry, `value`)
            values ('469db6ea8476d9b0150fc3551463e107', 1483856959, null)
            ON DUPLICATE KEY UPDATE `value`=null, expiry=1483856959 ==> (as called by) /***/***/public_html/includes/functions/sessions.php on line 69 <== in /***/***/public_html/includes/classes/db/mysql/query_factory.php on line 167

Although I do believe the above are default files, I'd like to mention that Dual Pricing module has been installed. Not sure which version exactly and it has been modified a bit by other coders.

Requester information has been obscured. Please identify if was a "personal" search or if was a spider to the best of your determination.

[Website Rob]

Not sure what you mean by "Requester information has been obscured" as an error msg. is an error msg.

To answer your question though, I can confirm it was a Google Bot.

[mc12345678]

Not sure what you mean by "Requester information has been obscured" as an error msg. is an error msg.

To answer your question though, I can confirm it was a Google Bot.

Not all error messages are created equally. :)

Having an error message identifies that there was an error. In this case, understanding the source/reason for the error message is important to working with it. Seems that there are several parts confirmed. Bot doesn't get $_SESSION data started, a session_id is generated and attempted to be stored even though there is no data to store with it. And it does appear that the default "result" of trying to feed an empty session is to push a string that is the result of base64_decode('null'); or there already exists something in the database that allows providing a stored value of 'null'. Either that or I've completely misunderstood how sessions and the sessions file work.

By the requestor information being obscured I was referring to what looked like would have been the ip address of the visitor. I can't say I see that error message much to know if it was to be the ip address of the store reporting the error or that of the one "causing" the error.

Regardless, at least for now it indicates that the problem isn't with session storage for cases when sessions work.

So presumably then the changes of zc 1.5.5a-d have not been applied and/or lat9s suggested modification as a result of not applying

[Website Rob]

So presumably then the changes of zc 1.5.5a-d have not been applied and/or lat9s suggested modification as a result of not applying

Are you stating this particular problem has been corrected in 1.5.5d?

[lat9]

Might want to flesh that out a bit. I tried your code with MySQL in STRICT_TRANS_TABLES mode and got a broken page with the error msg.

var-type undefined: stringIgnoreNull

That's because you're running ZC 1.5.5; the stringIgnoreNull value was added in Zen Cart 1.5.5a's /includes/classes/db/mysql/query_factory.php. You can safely use the ZC 1.5.5d version of that file on your 1.5.5 store.

[Website Rob]

Would like to point out some confusion though as this thread is about a "cannot be null" error in 1.5.5 and pretty close to what to I was experiencing. Was also not aware of the code change made in 1.5.5a till mentioned by mc12345678. I didn't see a Zen Version version number in your post on page 2 about using the "stringIgnoreNull" so not sure what version you were referring to for the change. Will try what you suggest though and see what results will be.

I also appreciate your help in the other, unrelated matter and glad you got it resolved so quickly.

[mc12345678]

Are you stating this particular problem has been corrected in 1.5.5d?

No, the overall problem at least as of the version 1.5.5d released what the 28th of December (second reported release version) had not specifically resolved the issue. Versions a-d at least offered the datatype that would have resolved the issue of an incorrect datatype reported when attempting to apply it's use.

It would allow going down at least one path made available (applying the datatype of stringIgnoreNull) which would maintain the way session data has previously been handled. Previously the "session data" was stored in the database as a string containing the word null. This was instead of treating a string that is fully capitalized with the word NULL as a 'value' of null (rather than as a string).

Changes made to further the expected use of such strict settings may still have other areas within ZC to be so minorly modified to mitigate such issues, for example the second release of 1.5.5d was actually to remove one of the "features" added that unfortunately caused issue with modifying product via the admin screens. It didn't fully incorporate the possibility of a database being set with strict settings and the impact on the admin side.

Now as to the comment about whether the NULL session data should be stored or not, almost seems like a chicken-egg situation and the answer could be that in order to meet one set of "requirements" it must be stored as a string containing null so that when it is read and decoded, that the result of such decoding is a value of NULL (not a string), but then on the flip side, until that string containing null is put into the database, reading the session data would return an empty string not a value of NULL and therefore would indicate that the _sess_read function prior to the data being written to the database does not provide the same response as what would be fed to the _sess_write function... so in that light of "conflict", I go back to what is the benefit of writing the session_id to the database where the session will be set to NULL if stringIgnoreNull is used or is set to "" if the session was not previously stored. That said, and upon some additional thought to not store a session of NULL would also require not setting/storing a session = "" unless an attempt to restore a session with data = "" would provide an equivalent result as returning that the session = null.

[lat9]

Would like to point out some confusion though as this thread is about a "cannot be null" error in 1.5.5 and pretty close to what to I was experiencing. Was also not aware of the code change made in 1.5.5a till mentioned by mc12345678. I didn't see a Zen Version version number in your post on page 2 about using the "stringIgnoreNull" so not sure what version you were referring to for the change. Will try what you suggest though and see what results will be.

I also appreciate your help in the other, unrelated matter and glad you got it resolved so quickly.

Rob, the issue is exactly what's being experienced on the site you manage (and you're welcome!).

[mc12345678]

Not sure what you mean by "Requester information has been obscured" as an error msg. is an error msg.

To answer your question though, I can confirm it was a Google Bot.

Would like to point out some confusion though as this thread is about a "cannot be null" error in 1.5.5 and pretty close to what to I was experiencing. Was also not aware of the code change made in 1.5.5a till mentioned by mc12345678. I didn't see a Zen Version version number in your post on page 2 about using the "stringIgnoreNull" so not sure what version you were referring to for the change. Will try what you suggest though and see what results will be.

I also appreciate your help in the other, unrelated matter and glad you got it resolved so quickly.

Rob, the issue is exactly what's being experienced on the site you manage (and you're welcome!).

Which was confirmed to be on target with the "why" the problem was occurring by identifying the "visitor"/visitor type (item in the spiders.txt file causing the visitor to be identified as a spider and more than likely the default sessions values) that caused the error.

So yeah, on the same/right page/topic. Hopefully as a part of the discussion you've also now started looking at applying the fixes identified up to and including ZC 1.5.5d.