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

SPython:

As I mentioned in one of the posts above the payment modules were missing after logging into Zencart Admin. The steps I took to resolve this was to replace the edited authorizenet_aim.php (varchar(32)) with the backup I had made of the original. I then restarted mariadb and logged into Zencart and the modules were listed. I then edited the file again with to replace bigint(20) with varchar(20) updated the module in Admin. I then looked at the table and still the transaction_id type is listed as bigint(20). Restarting mariadb or even rebooting the server does not resolve this and, of course, transactions throw an error with Strict enabled with bigint(20)
Correction - I misstyped - I replaced bigint(20) with varchar(32)

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.

DrByte:

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.

Thanks - will try that. I have already been looking for other files that may contain the string.

DrByte:

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.
Nope - the only other file that contains it is authorizenet_echeck.php which I am not using and have not enabled

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 ;)

DrByte:

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 ;)
OK - I downloaded v1.5.5d yesterday. Will install and let you know. Thank you for your advice (and tolerance) - it is greatly appreciated.

DrByte:

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 ;)

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 ;)