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

I'm using a fresh install of v154 on Windows.

Have an issue with authorize.net aim payment module. Payments are being accepted ok and order transactions are fine.

The issue is in admin when i'm trying to do a refund or void a transaction. Everything is processing on Authorize.net's end find, the refunds or voids are processing. The issue i'm getting is when it's posting back to update the table. I'm getting a "WARNING: An Error ocurred, please refresh the page and try again"

I checked the error logs on one refund, which is below. Looks like it's not updating properly on the post back and it's, just trying to insert it.

I've looked on the forum but haven't found a solution. Any help or pointing in the correct direction would be awesome.

On a side note, i'm using another zen store using v150 on the same server, with authorize.net AIM and i'm not having in any issues.

Thanks

[14-Dec-2015 23:12:22 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, 0, 0, 3, 'A duplicate transaction has been submitted. DUPLICATE TRANSACTION ATTEMPT ', 'credit', '', '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_type] => CREDIT\n [x_card_num] => XXXX2491\n [x_amount] => 1.80\n [x_trans_id] => 7795201288\n [url] => https://secure.authorize.net/gateway/transact.dll\n [Note] => Refund Issued - sales tax charged in error\n)\n', 'Array\n(\n [0] => 3\n [1] => 1\n [2] => 11\n [3] => A duplicate transaction has been submitted.\n [4] => \n [5] => P\n [6] => 0\n [7] => \n [8] => \n [9] => 1.80\n [10] => CC\n [11] => credit\n [12] => \n [13] => \n [14] => \n [15] => \n [16] => \n [17] => \n [18] => \n [19] => \n [20] => \n [21] => \n [22] => \n [23] => \n [24] => \n [25] => \n [26] => \n [27] => \n [28] => \n [29] => \n [30] => \n [31] => \n [32] => \n [33] => \n [34] => \n [35] => \n [36] => \n [37] => 0845F2EA77CA726A3B6132F3551D8A49\n [38] => \n [39] => \n [40] => \n [41] => \n [42] => \n [43] => \n [44] => \n [45] => \n [46] => \n [47] => \n [48] => \n [49] => \n [50] => XXXX2491\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)\n', 'December 14, 2015, 3:12 pm', '' ) ==> (as called by) C:\inetpub\wwwroot\paisano-store\includes\modules\payment\authorizenet_aim.php on line 692 <== in C:\inetpub\wwwroot\paisano-store\includes\classes\db\mysql\query_factory.php on line 155


======

Dec-14-2015 03:12:22
=================================

Response Code: 3.
Response Text: A duplicate transaction has been submitted.

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_type] => CREDIT
[x_card_num] => XXXX2491
[x_amount] => 1.80
[x_trans_id] => 7795201288
[url] => https://secure.authorize.net/gateway/transact.dll
[Note] => Refund Issued - sales tax charged in error
)


Results Received back from Authorizenet: Array
(
[0] => Response from gateway
[1] => 3
[2] => 1
[3] => 11
[4] => A duplicate transaction has been submitted.
[5] =>
[6] => P
[7] => 0
[8] =>
[9] =>
[10] => 1.80
[11] => CC
[12] => credit
[13] =>
[14] =>
[15] =>
[16] =>
[17] =>
[18] =>
[19] =>
[20] =>
[21] =>
[22] =>
[23] =>
[24] =>
[25] =>
[26] =>
[27] =>
[28] =>
[29] =>
[30] =>
[31] =>
[32] =>
[33] =>
[34] =>
[35] =>
[36] =>
[37] =>
[38] => 0845F2EA77CA726A3B6132F3551D8A49
[39] =>
[40] =>
[41] =>
[42] =>
[43] =>
[44] =>
[45] =>
[46] =>
[47] =>
[48] =>
[49] =>
[50] =>
[51] => XXXX2491
[52] => Visa
[53] =>
[54] =>
[55] =>
[56] =>
[57] =>
[58] =>
[59] =>
[60] =>
[61] =>
[62] =>
[63] =>
[64] =>
[65] =>
[66] =>
[67] =>
[68] =>
)


CURL communication info: Array
(
[url] => https://secure.authorize.net/gateway/transact.dll
[content_type] => text/html
[http_code] => 200
[header_size] => 263
[request_size] => 414
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 1.389
[namelookup_time] => 0
[connect_time] => 0.063
[pretransfer_time] => 1.264
[size_upload] => 225
[size_download] => 308
[speed_download] => 221
[speed_upload] => 161
[download_content_length] => 308
[upload_content_length] => 225
[starttransfer_time] => 1.389
[redirect_time] => 0
[certinfo] => Array
(
)

[redirect_url] =>
)


RAW data received:
*3*|*1*|*11*|*A duplicate transaction has been submitted.*|**|*P*|*0*|**|**|*1.80*|*CC*|*credit*|**|**|**|**|**|**|**|**|**|**| **|**|**|**|**|**|**|**|**|**|**|**|**|**|**|*0845F2EA77CA726A3B6132F3551D8A49*| **|**|**|**|**|**|**|**|**|**|**|**|*XXXX2491*|*Visa*|**|**|**|**|**|**|**|**|** |**|**|**|**|**|**|**



Also some other details.:

server OS: Windows NT 6.1 build 7601 (Windows Server 2008 R2 Standard Edition Service Pack 1) i586
Database: MySQL 5.1.57-community
HTTP Server: Microsoft-IIS/7.5
PHP Version: 5.3.13 (Zend: 2.3.0)
MYSQL is running in strict mode

Your log shows you were doing a refund. The transaction_id is blank when doing a refund, which is what is triggering that problem.

This is how we've fixed it for v1.5.5 and newer:
https://github.com/drbyte/zc-v1-seri...c5444994c6fea2

Quote:

---

Originally Posted by DrByte

Your log shows you were doing a refund. The transaction_id is blank when doing a refund, which is what is triggering that problem.

This is how we've fixed it for v1.5.5 and newer:
https://github.com/drbyte/zc-v1-seri...c5444994c6fea2

---

I am having a similar problem with the AIM authorize.net module. I see from the AIM_debug logs that the transaction has been approved but no order is received or written to the database (except the logs) and no emails are sent to either the merchant or the client. We have previously used the SIM module which worked except for erratic timeouts.
This is the error I am seeing in myDebug log:
PHP Fatal error: 1366:Incorrect integer value: '' for column 'transaction_id' at row 1

I am using PHP v. 7.0.9

Would appreciate advice on how to remedy this.

Here is the myDebug.log with personal info removed

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

[01-Nov-2016 16:42:42 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, 2, 12, 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] => 0.71\n [x_currency_code] => USD\n [x_market_type] => 0\n [x_card_num] => XXXXXXXXXXXXXXXXxxx\n [x_exp_date] => ****\n [x_card_code] => ****\n [x_email_customer] => TRUE\n [x_email_merchant] => TRUE\n [x_cust_id] => 2\n [x_invoice_num] => 12-BDlbtJ\n [x_first_name] => ***\n [x_last_name] => ***\n [x_company] => **** ****\n [x_address] => *** *** ave\n [x_city] => brooklyn\n [x_state] => New York\n [x_zip] => 11249\n [x_country] => United States\n [x_phone] => *********\n [x_email] => ***@***.com\n [x_ship_to_first_name] => ****\n [x_ship_to_last_name] => ****\n [x_ship_to_address] => **** *** ave\n [x_ship_to_city] => brooklyn\n [x_ship_to_state] => New York\n [x_ship_to_zip] => 11249\n [x_ship_to_country] => United States\n [x_description] => Deli Pint 16oz (qty: 1) \n [x_recurring_billing] => NO\n [x_customer_ip] => **.**.**.**\n [x_po_num] => Nov-01-2016 04:42:39\n [x_freight] => 0.00\n [x_tax_exempt] => FALSE\n [x_tax] => 0.06\n [x_duty] => 0\n [x_device_type] => 8\n [x_allow_partial_Auth] => FALSE\n [Date] => November 1, 2016, 4:42 pm\n [IP] => **.**.**.**\n [Session] =>*********\n [x_type] => AUTH_CAPTURE\n [url] => https://secure.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] => *****\n [5] => N\n [6] => ******\n [7] => 12-BDlbtJ\n [8] => Pint 16oz (qty: 1)\n [9] => 0.71\n [10] => CC\n [11] => auth_capture\n [12] => 2\n [13] => ****\n [14] => ****\n [15] => **** ****\n [16] => **** *** ave\n [17] => brooklyn\n [18] => New York\n [19] => 11249\n [20] => United States\n [21] => 2125290628\n [22] => \n [23] => ********######################\n [24] => ****\n [25] => ****\n [26] => \n [27] => **** *** ave\n [28] => brooklyn\n [29] => New York\n [30] => 11249\n [31] => United States\n [32] => 0.06\n [33] => 0.00\n [34] => 0.00\n [35] => FALSE\n [36] => Nov-01-2016 04:42:39\n [37] => *************\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] => XXXX***\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 1, 2016, 4:42 pm\n [69] => **.**.**.**\n [70] => ******\n [71] => *********\n [Expected-MD5-Hash] => ***********\n [HashMatchStatus] => PASS\n)\n', 'November 1, 2016, 4:42 pm', '******' ) ==> (as called by) /home/**/**/includes/modules/payment/authorizenet_aim.php on line 753 <== in /home/**/**/includes/classes/db/mysql/query_factory.php on line 167

Fogot to add: Zencart version 1.5.5a

mysql Ver 15.1 Distrib 10.1.18-MariaDB, for Linux (x86_64) using EditLine wrapper

@@SESSION.sql_mode |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |

I am using Zen Cart 1.5.5b,Apache/2.4.23 (Unix) OpenSSL/1.0.2h PHP/7.0.9 mod_fcgid/2.3.9 and Authorize AIM module to process transactions. All was working smoothly until I upgraded the server to Fedora 25. Now the client receives an error on checkout though the Authorize.net transaction goes through. Unfortunately, the client does not know this and so refreshes their browser and resubmits the order - multiple times. The transaction is not recorded in Zen Cart.
Relevant info from myDebug.log is:

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

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

Would greatly appreciate any advice or pointers. Something about this error seems familiar.

Are you using the Authorize.net AIM to process payments for Eprocessing's AIM emulator, and not actually for Authorize.net itself?

Ref: #15 & #17

I believe I am using the default Authorize.net AIM module with Zen Cart. The client who I configured and host the cart for has an account with Authorize.net.

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

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

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.

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

Quote:

---

Originally Posted by DrByte

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.

I meant: #17

Quote:

---

Originally Posted by DrByte

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

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.

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.

Quote:

---

Originally Posted by 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.

---

Quote:

---

Originally Posted by 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

---

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.

Quote:

---

Originally Posted by 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/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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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:

Code:

---

$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

Code:

---

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

Quote:

---

Originally Posted by 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] => 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)

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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] => 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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?

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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".

Quote:

---

Originally Posted by 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] => 04DA7F1E6340B3AE995D15BEB93F85EF5128359E58E747FB70903006B83900BBB01EB749F5B06D02 8D32B457031BF7F3765612B0F04530777A72D2474D83DE40
[Expected-MD5-Hash] => 5F02AD93F165BEC6AADA6C207FAC9679
[HashMatchStatus] => PASS
)


(*snip*)

Quote:

---

Originally Posted by 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'.

Quote:

---

Originally Posted by 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?

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by SPython

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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)

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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 ;)

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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 ;)