Issue with Authorize.net AIM updating table - error 1366 incorrect integer value

[SPython]

I also now realize why the problem seemed familiar as I encountered it at the beginning of November with 1.5.5a. Not sure how it was resolved - possible with 1.5.5.b
https://www.zen-cart.com/showthread....-integer-value

[SPython]

To verify - the transactions are being made directly through authorize.net and not through an emulator:
[x_type] => AUTH_CAPTURE
[url] => https://secure2.authorize.net/gateway/transact.dll

[SPython]

I have made a short term fix by disabling STRICT_TRANS_TABLES in my.cnf. Clearly this is not a good idea and it would be preferable to fix the code in Zen Cart - if that is where the problem lies.

[DrByte]

Making the change I posted in the discussion thread I referred to above should resolve the issue.

[SPython]

Making the change I posted in the discussion thread I referred to above should resolve the issue.

Thank you for your response - but precisely which change is that? I see at least three references above and one that refers to an AIM emulator - whereas I am using the default Authorize.net AIM module. As I mentioned, I upgraded to v1.5.5b from v1.5.5a and you state in one of your posts that the problem was fixed in the upgrade scripts.

[DrByte]

I meant: #17

[SPython]

I meant: #17

Thanks but that did not work. I changed both "bigint(20)" to "varchar(32)" in the Authorizenet_aim.php script as instructed - renabled STRICT_TRANS_TABLES in my.cnf - rebooted the server to be sure instead of just restarting mariadb and then ran a transaction. The same error occurred. The Authorizenet AIM transaction is process but it is not recorded/processed by Zencart or mysql.

As I mentioned earlier, I had Zencart v1.5.5b working perfectly with Fedora 24. The problem ONLY appeared when I upgraded the OS to Fedora 25 a few days ago. So an upgraded program (possibly mariadb) is not agreeing with the configuration of the Zencart authorizenet_aim.php script. I do not believe it is PHP itself as I had originally installed that from source and it is PHP Version: 7.0.9 (Zend: 3.0.0).

[DrByte]

The change is (apparently that your Fedora upgrade also updated) your version of MySQL/MariaDB. Newer versions enforce the STRICT field type rules.

I'm very surprised that change from bigint to varchar didn't change the error message ... because if it's varchar then there wouldn't be any reason to reject an empty-but-not-null string from being inserted. ... so it makes me wonder if the correct file was changed.
You could also manually change it in the authorizenet table itself, but that same section of code already checks to see if the field is changed, and if not then it changes it.

Additionally, if you're not actually ever using the data stored in the authorizenet table, you could turn off "Enable Database Storage" in your AIM module.

[SPython]

These are the versions of Mariadb before and after the OS upgrade:

(fc24) mysql Ver 15.1 Distrib 10.1.18-MariaDB, for Linux (x86_64) using EditLine wrapper
(fc25) mysql Ver 15.1 Distrib 10.1.19-MariaDB, for Linux (x86_64) using readline 5.1

the file edited per your instructions was /includes/modules/payment/authorizenet_aim.php

I can try turning off "Enable Database Storage" though I would like to keep as much data of the transactions as possible for export to offline databases.

The change is (apparently that your Fedora upgrade also updated) your version of MySQL/MariaDB. Newer versions enforce the STRICT field type rules.

I'm very surprised that change from bigint to varchar didn't change the error message ... because if it's varchar then there wouldn't be any reason to reject an empty-but-not-null string from being inserted. ... so it makes me wonder if the correct file was changed.
You could also manually change it in the authorizenet table itself, but that same section of code already checks to see if the field is changed, and if not then it changes it.

Additionally, if you're not actually ever using the data stored in the authorizenet table, you could turn off "Enable Database Storage" in your AIM module.

[DrByte]

These are the versions of Mariadb before and after the OS upgrade:

(fc24) mysql Ver 15.1 Distrib 10.1.18-MariaDB, for Linux (x86_64) using EditLine wrapper
(fc25) mysql Ver 15.1 Distrib 10.1.19-MariaDB, for Linux (x86_64) using readline 5.1

Ya, a fairly minor version change ... but if your my.cnf and/or mysqld/conf.d (or wherever imported alternate additional configs are kept on your server) have changed, then you might be dealing with different behavior simply because you've (maybe inadvertently) changed your configuration.