authorizenet_aim.php has :
$fieldOkay1 = (method_exists($sniffer, 'field_type')) ? $sniffer->field_type(TABLE_AUTHORIZENET, 'transaction_id', 'varchar(32)', true) : -1;
if ($fieldOkay1 !== true) {
$db->Execute("ALTER TABLE " . TABLE_AUTHORIZENET . " CHANGE transaction_id transaction_id varchar(32) default NULL");
Updating the module in admin does not change the transaction_id type in the mysql table immediately. Some while later it may change to varchar(32).
If I then enable STRICT_TRANS_TABLES and restart mariadb the table reverts to biginit(20) although authorizenet_aim.php has the transaction id as varchar(32).
So I am guessing that the table structure is being cached and restored on a reboot. Just a guess - but very frustrating.
I don't think it's a caching thing. Doesn't seem logical that a db would cache old schemas for automatic reverting.
I wonder if there's something else in your site that's making the change though. Perhaps doing a search of your entire site's PHP files for "bigint(20)" might be revealing. Admin->Tools->Developer's Toolkit->bottom field.
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
Just to be certain of no clash, and no accidental firing that's overwriting the aim changes, try making the same varchar(32) change to the echeck module.
Or just use the new authnet files from v1.5.5d which now has the varchar(32) changes built-in ;)
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
I am happy to report that after installing v1.5.5d the string varchar(32) appears permanently as the type for the transaction_id for authorizenet in mariadb. Also, after changing back to STRICT_TRANS_TABLES in my.cnf and restarting mariadb - transactions now go through with out error.
Thank you DrByte and all the Zen Cart programmers!
Yay!
I suspect the other module was rewriting things (although I'm surprised it was firing). Nevertheless, I'm glad the consistency between them has now resolved it.
Happy New Year ;)
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
Bookmarks