DrByte:

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/commit/98c6e43f3ad3ff7e0facbb9011c5444994c6fea2
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.

SPython:

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.

carlwhat:

#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.

DrByte:

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.

carlwhat:

#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] => C9C60A423B044B56EE303D4CE91308224280E9A8537A71B72D94A482F5F393CDAF463906DB6DE33658D9BCF5B3E23656D81AA2AE356B2E7A58964D1B5BC4287G\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)

SPython:

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.

SPython:

[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.

SPython:

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] => C9C60A423B044B56EE303D4CE91308224280E9A8537A71B72D94A482F5F393CDAF463906DB6DE33658D9BCF5B3E23656D81AA2AE356B2E7A58964D1B5BC4287G\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.

carlwhat:

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.

carlwhat:

"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?

carlwhat:

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.

carlwhat:

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.

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

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.

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.

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

Ignore last comment about varchar(32) not showing as the transaction id. I have logged back into the server and now it shows. Odd. I will now enable STRICT_TRANS_TABLES, restart the database, run a transaction and see if I get the same error.

Two things:

Do you have multiple authorize.net modules enabled?

The log you last posted only shows the request "sent" array, not the "response received".

DrByte:

Two things:

Do you have multiple authorize.net modules enabled?

The log you last posted only shows the request "sent" array, not the "response received".

Yes - just realized my error in pasting. Now with VARCHAR(32) and STRICT_TRANS_TABLES enabled the transaction goes through without error.
Below is the full AIM_Debug.log from this successful transaction:
Dec-28-2016 07:35:03

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] => XXXXXXXXXXXXXXXX7510
[x_exp_date] => ****
[x_card_code] => ****
[x_email_customer] => TRUE
[x_email_merchant] => TRUE
[x_cust_id] => 1
[x_invoice_num] => 107-WbyAoy
[x_first_name] => Harold
[x_last_name] => Pinter
[x_company] => Harold Pinter Movies
[x_address] => 436 East 20th Street
[x_city] => New York
[x_state] => New York
[x_zip] => 10024
[x_country] => United States
[x_phone] => xxxxxxxx
[x_email] => [email protected]
[x_ship_to_first_name] => Harold
[x_ship_to_last_name] => Pinter
[x_ship_to_address] => 436 East 20th Street
[x_ship_to_city] => New York
[x_ship_to_state] => New York
[x_ship_to_zip] => 10024
[x_ship_to_country] => United States
[x_description] => Deli Pint 16oz (qty: 1)
[x_recurring_billing] => NO
[x_customer_ip] => 34.5.96.243
[x_po_num] => Dec-28-2016 07:35:01
[x_freight] => 0.00
[x_tax_exempt] => FALSE
[x_tax] => 0.06
[x_duty] => 0
[x_device_type] => 8
[x_allow_partial_Auth] => FALSE
[Date] => December 28, 2016, 7:35 pm
[IP] => 34.5.96.243
[Session] => ebfiga0n6qtbkvpioerldp8n95
[x_type] => AUTH_CAPTURE
[url] => https://secure2.authorize.net/gateway/transact.dll
)

Results Received back from Authorizenet: Array
(
[0] => Response from gateway
[1] => 1
[2] => 1
[3] => 1
[4] => This transaction has been approved.
[5] => 033514
[6] => Y
[7] => 20333891394
[8] => 107-WbyAoy
[9] => Deli Pint 16oz (qty: 1)
[10] => 0.71
[11] => CC
[12] => auth_capture
[13] => 1
[14] => Harold
[15] => Pinter
[16] => Harold Pinter Movies
[17] => 436 East 20th Street
[18] => New York
[19] => New York
[20] => 10024
[21] => United States
[22] => xxxxxxxxx
[23] =>
[24] => [email protected]
[25] => Harold
[26] => Pinter
[27] =>
[28] => 436 East 20th Street
[29] => New York
[30] => New York
[31] => 10024
[32] => United States
[33] => 0.06
[34] => 0.00
[35] => 0.00
[36] => FALSE
[37] => Dec-28-2016 07:35:01
[38] => 5F02AD93F165BEC6AADA6C207FAC9679
[39] => M
[40] =>
[41] =>
[42] =>
[43] =>
[44] =>
[45] =>
[46] =>
[47] =>
[48] =>
[49] =>
[50] =>
[51] => XXXX7510
[52] => Visa
[53] =>
[54] =>
[55] =>
[56] =>
[57] =>
[58] =>
[59] =>
[60] =>
[61] =>
[62] =>
[63] =>
[64] =>
[65] =>
[66] =>
[67] =>
[68] =>
[69] => December 28, 2016, 7:35 pm
[70] => 34.5.96.243
[71] => ebfiga0n6qtbkvpioerldp8n95
[72] => 04DA7F1E6340B3AE995D15BEB93F85EF5128359E58E747FB70903006B83900BBB01EB749F5B06D028D32B457031BF7F3765612B0F04530777A72D2474D83DE40
[Expected-MD5-Hash] => 5F02AD93F165BEC6AADA6C207FAC9679
[HashMatchStatus] => PASS
)

(snip)

DrByte:

Two things:

Do you have multiple authorize.net modules enabled?

The log you last posted only shows the request "sent" array, not the "response received".
I posted a full reply but a notice appeared that it needed to be approved by a moderator. I have only one module of Authorizenet enabled - the AIM module. Also with varchar(32) and STRICT_TRANS_TABLE enabled the transaction goes through without error. I included the full authorize aim log in the post awaiting approval by your moderator. (My error in the previous post in pasting a partial log.)

Curious. The transaction ID there is '20333891394'.

DrByte:

Curious. The transaction ID there is '20333891394'.

Excuse my ignorance - what does that signify?

Apropos - I now seem to have a new problem. When I login to ZenCart Admin the Payment Modules are not listed. I get:

Payment Modules
WARNING: An Error occurred, please refresh the page and try again.
Modules Sort Order Orders Status Action

Refreshing the browser, deleting the cache, logging in and out of the desktop does not help. The files are all there on the server and the permissions have not changed. I do not see that editing a couple of lines in one file would cause this. Any idea?

SPython:

Excuse my ignorance - what does that signify?

Apropos - I now seem to have a new problem. When I login to ZenCart Admin the Payment Modules are not listed. I get:

Payment Modules
WARNING: An Error occurred, please refresh the page and try again.
Modules Sort Order Orders Status Action

Refreshing the browser, deleting the cache, logging in and out of the desktop does not help. The files are all there on the server and the permissions have not changed. I do not see that editing a couple of lines in one file would cause this. Any idea?

This appears to have been resolved by restarting mariadb

SPython:

DrByte:

Curious. The transaction ID there is '20333891394'.

Excuse my ignorance - what does that signify?
Given that the module is getting a transaction ID back from Authnet, it doesn't make sense why it's trying to insert a blank transaction id into the database as your SQL errors are showing.

SPython:

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?

some posts later:

Yes - just realized my error in pasting. Now with VARCHAR(32) and STRICT_TRANS_TABLES enabled the transaction goes through without error.
Below is the full AIM_Debug.log from this successful transaction:

i am glad to see you have resolved this error.

to answer your question from many posts ago, i persisted in my belief because you can not have an invalid integer error when inserting a value into a field of type varchar.

best.

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)