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

[SPython]

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.

No, there have not been any changes to the configuration files and an upgrade would not overwrite them. I do recall that I encountered this problem about a month ago with v.1.5.5.a I cannot remember exactly how I remedied that (as I have dealt with so many issues in the interim) but I may have applied the remedy you mentioned here
https://github.com/drbyte/zencart/co...c5444994c6fea2
Of course, the authorizenet_aim.php scripts were already changed in v.1.5.5b and worked without a glitch (or maybe it was the update to v.1.5.5b that fixed the problem).
If you have any other suggestions on how we may debug this problem I would like to discover the cause.

[carlwhat]

Of course, the authorizenet_aim.php scripts were already changed in v.1.5.5b and worked without a glitch (or maybe it was the update to v.1.5.5b that fixed the problem).
If you have any other suggestions on how we may debug this problem I would like to discover the cause.

#1 i agree with drByte that changing the field type of transaction_id to varchar(32) should address this problem. can you post the structure of the table from phpMyadmin or some other tool?
#2 i have been looking at your posting of the original error as well as the code. you have an approved transaction with a blank transaction_id? how is that possible? from the code, the transaction_id is part 6 of the return string, which from your error log is:

[5] => N\n [6] => ******\n [7] => 12-BDlbtJ\n

have you modified the error log in that section? it would be nice to see the actual return string because it should be a number for a transaction_id.

#3 after modifying the table, can you post the new error log?

there is something adrift here. and changing the structure of the table should address this problem; but frankly i'm confused as to why your transaction_id would be blank here.

best.

[SPython]

#1 i agree with drByte that changing the field type of transaction_id to varchar(32) should address this problem. can you post the structure of the table from phpMyadmin or some other tool?
#2 i have been looking at your posting of the original error as well as the code. you have an approved transaction with a blank transaction_id? how is that possible? from the code, the transaction_id is part 6 of the return string, which from your error log is:

[5] => N\n [6] => ******\n [7] => 12-BDlbtJ\n

have you modified the error log in that section? it would be nice to see the actual return string because it should be a number for a transaction_id.

#3 after modifying the table, can you post the new error log?

there is something adrift here. and changing the structure of the table should address this problem; but frankly i'm confused as to why your transaction_id would be blank here.

best.

Thank you for your response. You were looking at an earlier report from November 1st when this error first occurred with v.1.5.5a. This problem was resolved with the v1.5.5b upgrade. The most recent problem - reported on November 29th - has appeared after I upgraded the OS to Fedora 25 from FC24. I will post the full error log when the error was occurring with STRICT_TRANS_TABLES enabled (with personal data blanked) and the table structure later.

[carlwhat]

Ref: #15 & #17

i would again look at #17 here.

your error from 11/29 pretty clearly states:

[29-Nov-2016 20:20:03 UTC] PHP Fatal error: 1366:Incorrect integer value: '' for column 'transaction_id' at row 1 :: insert into authorizenet

now, the solution provided in #17 involves changing that field type to varchar(32). if you have changed the field type to varchar, i find it difficult to imagine an incorrect integer value. and i just downloaded 1.5.5b, and in that code, the field looks still as bigint(20).

finally, on line 432 of the authorizenet_aim.php code, we have the following:

$this->transaction_id .= ' ***NOTE: Held for review by merchant.';

this situation is based on certain criteria; however when those criteria are hit, the transaction_id would most certainly be a string, and on line 440, we have

$this->_debugActions($response, $order_time, $sessID);

and in the _debugActions function is where we insert the transaction_id into the database, and now we most certainly have a problem that removing strict mode will do nothing to resolve.

best.

[SPython]

#1 i agree with drByte that changing the field type of transaction_id to varchar(32) should address this problem. can you post the structure of the table from phpMyadmin or some other tool?
#2 i have been looking at your posting of the original error as well as the code. you have an approved transaction with a blank transaction_id? how is that possible? from the code, the transaction_id is part 6 of the return string, which from your error log is:

[5] => N\n [6] => ******\n [7] => 12-BDlbtJ\n

have you modified the error log in that section? it would be nice to see the actual return string because it should be a number for a transaction_id.

#3 after modifying the table, can you post the new error log?

there is something adrift here. and changing the structure of the table should address this problem; but frankly i'm confused as to why your transaction_id would be blank here.

best.

Below is the full myDEBUG log from Nov.29 with only ip addresses and personal information altered. The sql-mode was: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE _ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY

If I remove STRICT_TRANS_TABLES the program does not throw an error and the transaction is recorded in ZenCart and appears in the Admin Section and the client is notified by email etc. Changing the relevant field type from bigint(20) to varchar(32) with STRICT_TRANS_TABLES enabled does not resolve the problem and throws the same error.
As mentioned previously, v1.5.5.b worked flawlessly with Fedora 24 and the problem only appeared with the upgrade to FC25.

myDebug log Nov.29

[29-Nov-2016 07:03:10 UTC] Request URI: /index.php?main_page=checkout_process, IP address: 192.36.228.185
#1 trigger_error() called at [/home/user/www/includes/classes/db/mysql/query_factory.php:167]
#2 queryFactory->show_error() called at [/home/user/www/includes/classes/db/mysql/query_factory.php:139]
#3 queryFactory->set_error() called at [/home/user/www/includes/classes/db/mysql/query_factory.php:266]
#4 queryFactory->Execute() called at [/home/user/www/includes/modules/payment/authorizenet_aim.php:753]
#5 authorizenet_aim->_debugActions() called at [/home/user/www/includes/modules/payment/authorizenet_aim.php:440]
#6 authorizenet_aim->before_process() called at [/home/user/www/includes/classes/payment.php:245]
#7 payment->before_process() called at [/home/user/www/includes/modules/checkout_process.php:84]
#8 require(/home/user/www/includes/modules/checkout_process.php) called at [/home/user/www/includes/modules/pages/checkout_process/header_php.php:14]
#9 require(/home/user/www/includes/modules/pages/checkout_process/header_php.php) called at [/home/user/www/index.php:36]

[29-Nov-2016 07:03:10 UTC] PHP Fatal error: 1366:Incorrect integer value: '' for column 'transaction_id' at row 1 :: insert into authorizenet (id, customer_id, order_id, response_code, response_text, authorization_type, transaction_id, sent, received, time, session_id) values (NULL, 80, 46, 1, 'This transaction has been approved.', 'auth_capture', '', 'Array\n(\n [x_login] => *******\n [x_tran_key] => *******\n [x_relay_response] => FALSE\n [x_delim_data] => TRUE\n [x_delim_char] => |\n [x_encap_char] => *\n [x_version] => 3.1\n [x_solution_id] => A1000003\n [x_method] => CC\n [x_amount] => 459.33\n [x_currency_code] => USD\n [x_market_type] => 0\n [x_card_num] => XXXXXXXXXXXXXXXX2057\n [x_exp_date] => ****\n [x_card_code] => ****\n [x_email_customer] => TRUE\n [x_email_merchant] => TRUE\n [x_cust_id] => 80\n [x_invoice_num] => 46-cYtmBv\n [x_first_name] => Davis\n [x_last_name] => Lloyd\n [x_company] => \n [x_address] => 23 E Anywhere St\n [x_city] => Providence\n [x_state] => Rhode Island\n [x_zip] => 02907\n [x_country] => United States\n [x_phone] => 407-465-1309\n [x_email] => anyperson######################\n [x_ship_to_first_name] => Any\n [x_ship_to_last_name] => Person\n [x_ship_to_address] => 23 E Anywhere St\n [x_ship_to_city] => Providence\n [x_ship_to_state] => Rhode Island\n [x_ship_to_zip] => 02907\n [x_ship_to_country] => United States\n [x_description] => Oranges 40 P.C. - 128 oz (qty: 1) + Oranges Apples - 32 oz (qty: 1) + Lemons#2 8oz (qty: 1) + Pomegranates 4oz (qty: 1) + Bananas 4oz (qty: 1) + Strange Fruit H.S. 4oz (qty: 1) + Passion Fruit C.P. 4oz (qty: 1) + Some More Bananas CP 4oz (qty: 1) + Yoghurt Light CP 4oz (qty: 1) + Persimmon 4oz (qty: 1) + Avocaco 4oz (qty: 1) \n [x_recurring_billing] => NO\n [x_customer_ip] => 192.34.229.186\n [x_po_num] => Nov-29-2016 07:03:05\n [x_freight] => 25.08\n [x_tax_exempt] => FALSE\n [x_tax] => 0.00\n [x_duty] => 0\n [x_device_type] => 8\n [x_allow_partial_Auth] => FALSE\n [Date] => November 29, 2016, 7:03 am\n [IP] => 192.34.229.186\n [Session] => jqksouobv5b8japai0q62r1jo6\n [x_type] => AUTH_CAPTURE\n [url] => https://secure2.authorize.net/gateway/transact.dll\n)\n', 'Array\n(\n [0] => 1\n [1] => 1\n [2] => 1\n [3] => This transaction has been approved.\n [4] => 100231\n [5] => Z\n [6] => 20266280746\n [7] => 46-cYtmBv\n [8] => Oranges 40 P.C. - 128 oz (qty: 1) + Oranges Apples - 32 oz (qty: 1) + Lemons#2 8oz (qty: 1) + Pomegranates 4oz (qty: 1) + More Bananas 4oz (qty: 1) + Bananas 4oz (qty: 1) + Strange Fruit 4oz (qty: 1) + Cadmi\n [9] => 459.33\n [10] => CC\n [11] => auth_capture\n [12] => 80\n [13] => Person\n [14] => Any\n [15] => \n [16] => 23 E Anywhere St\n [17] => Providence\n [18] => Rhode Island\n [19] => 02907\n [20] => United States\n [21] => 402-486-1703\n [22] => \n [23] => anyperson######################\n [24] => Person\n [25] => Any\n [26] => \n [27] => 23 E Anywhere St\n [28] => Providence\n [29] => Rhode Island\n [30] => 02907\n [31] => United States\n [32] => 0.00\n [33] => 0.00\n [34] => 25.08\n [35] => FALSE\n [36] => Nov-29-2016 07:03:05\n [37] => 5646FDC5976632BEBE3DC1996012FCFC\n [38] => M\n [39] => \n [40] => \n [41] => \n [42] => \n [43] => \n [44] => \n [45] => \n [46] => \n [47] => \n [48] => \n [49] => \n [50] => XXXX2046\n [51] => Visa\n [52] => \n [53] => \n [54] => \n [55] => \n [56] => \n [57] => \n [58] => \n [59] => \n [60] => \n [61] => \n [62] => \n [63] => \n [64] => \n [65] => \n [66] => \n [67] => \n [68] => November 29, 2016, 7:03 am\n [69] => 192.34.229.186\n [70] => jqksouobv5b8japai0q62r1jo6\n [71] => C9C60A423B044B56EE303D4CE91308224280E9A8537A71B72D94A482F5F393CDAF463906DB6DE336 58D9BCF5B3E23656D81AA2AE356B2E7A58964D1B5BC4287G\n [Expected-MD5-Hash] => 5646FDC5976632BEBE3DC1996012FCFC\n [HashMatchStatus] => PASS\n)\n', 'November 29, 2016, 7:03 am', 'jqksouobv5b8japai0q62r1jo6' ) ==> (as called by) /home/user/www/includes/modules/payment/authorizenet_aim.php on line 753 <== in /home/user/www/includes/classes/db/mysql/query_factory.php on line 167
myDEBUG-1480402985-293085.log (END)

[carlwhat]

As mentioned previously, v1.5.5.b worked flawlessly with Fedora 24 and the problem only appeared with the upgrade to FC25.

on the upgrade, the sql mode got changed. i'm not sure why you do not just remove STRICT from the current mode.

[29-Nov-2016 07:03:10 UTC] PHP Fatal error: 1366:Incorrect integer value: '' for column 'transaction_id' at row 1 ::

"you can lead a horse to water, but you can not make him drink..."

as i have stated numerous times, you have NOT changed the type for transaction_id to varchar(32). if you had, you would NOT receive an incorrect integer value error. you might receive an other error, but not an incorrect integer error. i'm not sure how i can make that any clearer.

insert into authorizenet (id, customer_id, order_id, response_code, response_text, authorization_type, transaction_id, sent, received, time, session_id) values (NULL, 80, 46, 1, 'This transaction has been approved.', 'auth_capture', '', 'Array\n(\n [x_login] => *******\n [x_tran_key] => *******\n [x_relay_response] => FALSE\n [x_delim_data] => TRUE\n [x_delim_char] => |\n [x_encap_char] => *\n [x_version] => 3.1\n [x_solution_id] => A1000003\n [x_method] => CC\n [x_amount] => 459.33\n [x_currency_code] => USD\n [x_market_type] => 0\n [x_card_num] => XXXXXXXXXXXXXXXX2057\n [x_exp_date] => ****\n [x_card_code] => ****\n [x_email_customer] => TRUE\n [x_email_merchant] => TRUE\n [x_cust_id] => 80\n [x_invoice_num] => 46-cYtmBv\n [x_first_name] => Davis\n [x_last_name] => Lloyd\n [x_company] => \n [x_address] => 23 E Anywhere St\n [x_city] => Providence\n [x_state] => Rhode Island\n [x_zip] => 02907\n [x_country] => United States\n [x_phone] => 407-465-1309\n [x_email] => anyperson######################\n [x_ship_to_first_name] => Any\n [x_ship_to_last_name] => Person\n [x_ship_to_address] => 23 E Anywhere St\n [x_ship_to_city] => Providence\n [x_ship_to_state] => Rhode Island\n [x_ship_to_zip] => 02907\n [x_ship_to_country] => United States\n [x_description] => Oranges 40 P.C. - 128 oz (qty: 1) + Oranges Apples - 32 oz (qty: 1) + Lemons#2 8oz (qty: 1) + Pomegranates 4oz (qty: 1) + Bananas 4oz (qty: 1) + Strange Fruit H.S. 4oz (qty: 1) + Passion Fruit C.P. 4oz (qty: 1) + Some More Bananas CP 4oz (qty: 1) + Yoghurt Light CP 4oz (qty: 1) + Persimmon 4oz (qty: 1) + Avocaco 4oz (qty: 1) \n [x_recurring_billing] => NO\n [x_customer_ip] => 192.34.229.186\n [x_po_num] => Nov-29-2016 07:03:05\n [x_freight] => 25.08\n [x_tax_exempt] => FALSE\n [x_tax] => 0.00\n [x_duty] => 0\n [x_device_type] => 8\n [x_allow_partial_Auth] => FALSE\n [Date] => November 29, 2016, 7:03 am\n [IP] => 192.34.229.186\n [Session] => jqksouobv5b8japai0q62r1jo6\n [x_type] => AUTH_CAPTURE\n [url] => https://secure2.authorize.net/gateway/transact.dll\n)\n', 'Array\n(\n [0] => 1\n [1] => 1\n [2] => 1\n [3] => This transaction has been approved.\n [4] => 100231\n [5] => Z\n [6] => 20266280746\n [7] => 46-cYtmBv\n [8] => Oranges 40 P.C. - 128 oz (qty: 1) + Oranges Apples - 32 oz (qty: 1) + Lemons#2 8oz (qty: 1) + Pomegranates 4oz (qty: 1) + More Bananas 4oz (qty: 1) + Bananas 4oz (qty: 1) + Strange Fruit 4oz (qty: 1) + Cadmi\n [9] => 459.33\n [10] => CC\n [11] => auth_capture\n [12] => 80\n [13] => Person\n [14] => Any\n [15] => \n [16] => 23 E Anywhere St\n [17] => Providence\n [18] => Rhode Island\n [19] => 02907\n [20] => United States\n [21] => 402-486-1703\n [22] => \n [23] => anyperson######################\n [24] => Person\n [25] => Any\n [26] => \n [27] => 23 E Anywhere St\n [28] => Providence\n [29] => Rhode Island\n [30] => 02907\n [31] => United States\n [32] => 0.00\n [33] => 0.00\n [34] => 25.08\n [35] => FALSE\n [36] => Nov-29-2016 07:03:05\n [37] => 5646FDC5976632BEBE3DC1996012FCFC\n [38] => M\n [39] => \n [40] => \n [41] => \n [42] => \n [43] => \n [44] => \n [45] => \n [46] => \n [47] => \n [48] => \n [49] => \n [50] => XXXX2046\n [51] => Visa\n [52] => \n [53] => \n [54] => \n [55] => \n [56] => \n [57] => \n [58] => \n [59] => \n [60] => \n [61] => \n [62] => \n [63] => \n [64] => \n [65] => \n [66] => \n [67] => \n [68] => November 29, 2016, 7:03 am\n [69] => 192.34.229.186\n [70] => jqksouobv5b8japai0q62r1jo6\n [71] => C9C60A423B044B56EE303D4CE91308224280E9A8537A71B72D94A482F5F393CDAF463906DB6DE336 58D9BCF5B3E23656D81AA2AE356B2E7A58964D1B5BC4287G\n [Expected-MD5-Hash] => 5646FDC5976632BEBE3DC1996012FCFC\n [HashMatchStatus] => PASS\n)\n', 'November 29, 2016, 7:03 am', 'jqksouobv5b8japai0q62r1jo6' ) ==> (as called by) /home/user/www/includes/modules/payment/authorizenet_aim.php on line 753 <== in /home/user/www/includes/classes/db/mysql/query_factory.php on line 167
myDEBUG-1480402985-293085.log (END)

you have some other problem. index 6 on your array contains the transaction_id value. its value is 20266280746. and yet in your sql insert statement, the value is a blank string. something is adrift in your code. you have the transaction_id in the return string value, but not in the value of transaction_id on the insert statement.

i am sorry that i have not been able to help you... i have tried... but i find myself repeating things that i have previously stated, so i am not sure what more i can do to help you with this issue.

i do wish you luck in resolving it to your satisfaction.

best.

[SPython]

on the upgrade, the sql mode got changed. i'm not sure why you do not just remove STRICT from the current mode.

As I stated - I did remove STRICT from the my.cnf - it is the ONLY way that v1.5.5b would work after the upgrade to fC25. With it enabled it will throw an error whether the transaction_id is changed to varchar(32) or not.

"you can lead a horse to water, but you can not make him drink..."

as i have stated numerous times, you have NOT changed the type for transaction_id to varchar(32). if you had, you would NOT receive an incorrect integer value error. you might receive an other error, but not an incorrect integer error. i'm not sure how i can make that any clearer.

I do not know how I can state any clearer (please read above) that I DID make those changes to the script to the letter and also rebooted the server to ensure everything was loaded afresh. Then I ran a few transactions and still got the same error. Why do you persist in your disbelief?

you have some other problem. index 6 on your array contains the transaction_id value. its value is 20266280746. and yet in your sql insert statement, the value is a blank string. something is adrift in your code. you have the transaction_id in the return string value, but not in the value of transaction_id on the insert statement.

That might well be - but it is not my code - it is Zen Cart's.

i am sorry that i have not been able to help you... i have tried... but i find myself repeating things that i have previously stated, so i am not sure what more i can do to help you with this issue.

i do wish you luck in resolving it to your satisfaction.

best.

[SPython]

Just upgraded from v1.5.5b to v1.5.5c
Problem described above persists. Throws an error with STRICT_TRANS_TABLES enabled in my.cnf

[DrByte]

Observations:

1. Not sure why your site is receiving an empty value ('') as Transaction ID. Would be helpful to see the logged response data. See later below.

2. Even if it is getting an empty value for transaction ID, the PHP code in the module (line 744) checks to see if the transaction_id value is an empty string, and if it's not then it allows it to be put through. Now, it's treating it as "BIGINT(20)", which (in simple terms) is just "a very long integer of up to 20 digits". And, as far as the AIM spec goes, that's exactly what they say to treat it as.
Now, for other gateways that "emulate" the AIM protocol, such as E-processing Network, they've been sending transaction_id values with letters too, and longer than 20 chars. Hence the discussion several posts back to change it away from BIGINT(20) to a VARCHAR (character/string) field.
Now, if you try to put a string, even empty, into a field that's supposed to be INT/BIGINT/TINYINT then it's gonna throw the error you're reporting.
So, if you did change the code to have it handle varchar (and assuming the database allowed the change to take effect (you didn't confirm the actual new structure of the field from phpMyAdmin after making the PHP change)), then even trying to put an empty string into a varchar/string field, would not throw the error you're reporting.

3. Back to line 744 again. If it finds that the transaction_id *is* an empty string value, then line 746 kicks in and sets the value to "NULL", which ZC v155b/v155c will translate into a literal NULL value in the query being sent to the db. And, since the field is configured to accept a null then no error would be thrown.
But the SQL queries you've been quoting don't show it being treated as a null anyway. They all show '' (empty string) as the value it's trying to insert.

So, again, we're back to two problems:
a) it's checking for an empty value, and finding it "not empty", so it's treating it as a string
b) and trying to insert an empty string into a number-only field.


v155c does NOT have the change from BIGINT(20) to VARCHAR(32). Maybe it should have (for the sake of clones like E-Processing merchants), but still the issue remains that something odd is in the data being received as transaction_id.
While changing the code from BIGINT to VARCHAR again should bandage it, the problem still remains that your site isn't firing the null when it should.


It would be helpful to see the actual response coming back from Authorize.net. This can be obtained by turning on Debug Log To File in the AIM module settings. Then do a transaction, and look in the /logs/ folder for the AIM log file/s it generated. You might already have some if the switch is already set to log to file.

Also, making the bigint(20) to varchar(32) change again on lines 761, 763 would be good. Then log into your Admin and click Edit on the AIM module settings (such as to set the debug log setting). This will fire lines 761,763 to make the change in the db. Then look at the transaction_id field in the authorizenet table in your db, using phpMyAdmin, and check whether the change took place in the table's structure.

Armed with the results of these last two items, it may be easier to troubleshoot from this end.

[SPython]

Observations:

1. Not sure why your site is receiving an empty value ('') as Transaction ID. Would be helpful to see the logged response data. See later below.

2. Even if it is getting an empty value for transaction ID, the PHP code in the module (line 744) checks to see if the transaction_id value is an empty string, and if it's not then it allows it to be put through. Now, it's treating it as "BIGINT(20)", which (in simple terms) is just "a very long integer of up to 20 digits". And, as far as the AIM spec goes, that's exactly what they say to treat it as.
Now, for other gateways that "emulate" the AIM protocol, such as E-processing Network, they've been sending transaction_id values with letters too, and longer than 20 chars. Hence the discussion several posts back to change it away from BIGINT(20) to a VARCHAR (character/string) field.
Now, if you try to put a string, even empty, into a field that's supposed to be INT/BIGINT/TINYINT then it's gonna throw the error you're reporting.
So, if you did change the code to have it handle varchar (and assuming the database allowed the change to take effect (you didn't confirm the actual new structure of the field from phpMyAdmin after making the PHP change)), then even trying to put an empty string into a varchar/string field, would not throw the error you're reporting.

3. Back to line 744 again. If it finds that the transaction_id *is* an empty string value, then line 746 kicks in and sets the value to "NULL", which ZC v155b/v155c will translate into a literal NULL value in the query being sent to the db. And, since the field is configured to accept a null then no error would be thrown.
But the SQL queries you've been quoting don't show it being treated as a null anyway. They all show '' (empty string) as the value it's trying to insert.

So, again, we're back to two problems:
a) it's checking for an empty value, and finding it "not empty", so it's treating it as a string
b) and trying to insert an empty string into a number-only field.


v155c does NOT have the change from BIGINT(20) to VARCHAR(32). Maybe it should have (for the sake of clones like E-Processing merchants), but still the issue remains that something odd is in the data being received as transaction_id.
While changing the code from BIGINT to VARCHAR again should bandage it, the problem still remains that your site isn't firing the null when it should.


It would be helpful to see the actual response coming back from Authorize.net. This can be obtained by turning on Debug Log To File in the AIM module settings. Then do a transaction, and look in the /logs/ folder for the AIM log file/s it generated. You might already have some if the switch is already set to log to file.

Also, making the bigint(20) to varchar(32) change again on lines 761, 763 would be good. Then log into your Admin and click Edit on the AIM module settings (such as to set the debug log setting). This will fire lines 761,763 to make the change in the db. Then look at the transaction_id field in the authorizenet table in your db, using phpMyAdmin, and check whether the change took place in the table's structure.

Armed with the results of these last two items, it may be easier to troubleshoot from this end.

I always have debugging turned on. The result of myDEBUG-*.log for the last transaction with STRICT enabled is the same in pertinent respects to my post of November 1st in this thread. I include the AIM_Debug_*.log below. The problem I am now encountering is that I edited authorizenet_aim.php per your instructions substituting varchar(32) for bigint(20) and then updated the module in admin - but mysql continues to show bigint(20) as the transaction id in the table. Restarting the mysql database does not resolve this. What am I missing?

MariaDB [spzcatalog]> show columns from authorizenet;
+--------------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------------+------------------+------+-----+---------+----------------+
| id | int(11) unsigned | NO | PRI | NULL | auto_increment |
| customer_id | int(11) | NO | | 0 | |
| order_id | int(11) | NO | | 0 | |
| response_code | int(1) | NO | | 0 | |
| response_text | varchar(255) | NO | | | |
| authorization_type | varchar(50) | NO | | | |
| transaction_id | bigint(20) | YES | | NULL | |
| sent | longtext | NO | | NULL | |
| received | longtext | NO | | NULL | |
| time | varchar(50) | NO | | | |
| session_id | varchar(255) | NO | | | |
+--------------------+------------------+------+-----+---------+----------------+

AIM_Debug.log:
Dec-27-2016 11:02:56
=================================

Response Code: 1.
Response Text: This transaction has been approved.

Sending to Authorizenet: Array
(
[x_login] => *******
[x_tran_key] => *******
[x_relay_response] => FALSE
[x_delim_data] => TRUE
[x_delim_char] => |
[x_encap_char] => *
[x_version] => 3.1
[x_solution_id] => A1000003
[x_method] => CC
[x_amount] => 0.71
[x_currency_code] => USD
[x_market_type] => 0
[x_card_num] => XXXXXXXXXXXXXXXX6370
[x_exp_date] => ****
[x_card_code] => ****
[x_email_customer] => TRUE
[x_email_merchant] => TRUE
[x_cust_id] => 1
[x_invoice_num] => 106-XcMaPY
[x_first_name] => Harold
[x_last_name] => Pinter
[x_company] => Harold Pinter Movies
[x_address] => 53 Somewhere Street
[x_city] => New York
[x_state] => New York
[x_zip] => 10000
[x_country] => United States
[x_phone] => 212-410-4610
[x_email] => [email protected]
[x_ship_to_first_name] => Harold
[x_ship_to_last_name] => Pinter
[x_ship_to_address] => 53 Somewhere Street
[x_ship_to_city] => New York
[x_ship_to_state] => New York
[x_ship_to_zip] => 10000
[x_ship_to_country] => United States
[x_description] => Deli Pint 16oz (qty: 1)
[x_recurring_billing] => NO
[x_customer_ip] => 73.2.56.325
[x_po_num] => Dec-27-2016 11:02:52
[x_freight] => 0.00
[x_tax_exempt] => FALSE
[x_tax] => 0.06
[x_duty] => 0