Upgrading MySQL

[briandmiller]

I recently upgraded MySQL on my Win2k server from 3.x to 5.x(current).

Some of Zen Cart continues to work but I just found out that part of it does not. We use Authorize.net as our gateway. ZenCart continues to accept new users and processes cc transactions to Authorize.net. We get the appropriate email response from Authorize.net. Zen Cart does not send any emails regarding the order and in fact does not show the new orders under the Admin section. Other emails go out fine. Just seems to be missing the database part of the orders and not the user registration.

Any ideas out there.

Thanks-

Brian Miller

[DrByte]

What version of Zen Cart are you using?
What version of IIS?
What version of PHP? Did you upgrade PHP at the same time as MySQL ?
Did you research MySQL5 compatibility vs Zen Cart before upgrading?

[briandmiller]

What version of Zen Cart are you using?

Zen Cart 1.3.0.1
Database Patch Level: 1.3.0.1

What version of IIS?
HTTP Server: Microsoft-IIS/5.0

What version of PHP?
PHP Version: 4.4.2 (Zend: 1.3.0)

Database: MySQL 5.0.22-community-max-nt


Did you upgrade PHP at the same time as MySQL ? No

Did you research MySQL5 compatibility vs Zen Cart before upgrading?

I saw that it was not officially supported. There was another app that I was interested in hosting that needed the later version of MySQL.

[DrByte]

Are you using Authorize.net "AIM" service? or SIM?

What you're reporting is very bizarre, since it suggests (assuming AIM) that cURL was able to talk to authorize.net, but that somehow the reply back was unsuccessful.
When the customer pays, do they get a "congrats, successful order" message on-screen? or a CC failure notice, or a timeout?

[briandmiller]

I am using AIM.


Hmmmm. I just went to test with a purchase myself and everything worked fine. Perhaps because I am an existing user. It worked fine up to a certain point that seems like it was when I made the MySQL change. Users are reporting that they submit a completed transaction and they don't get any web response. They ofter do a duplicate order submission because they are expecting a response and don't get it.

I'll test with a new registration and let you know. Meanwhile - Any thoughts?

[DrByte]

Using AIM, you can enable the "Enable Database Storage" option in the module's settings in Zen Cart admin.
Then you can view the authorizenet table in your database to see what the responses are that are coming back from authorize.net for each attempted authorization.
Perhaps that will lend a clue.

[briandmiller]

Are you using Authorize.net "AIM" service? or SIM?

What you're reporting is very bizarre, since it suggests (assuming AIM) that cURL was able to talk to authorize.net, but that somehow the reply back was unsuccessful.
When the customer pays, do they get a "congrats, successful order" message on-screen? or a CC failure notice, or a timeout?

My mistake. I am not using "AIM" so I must be using "SIM". It's the plain Authorize.net module listed above the "AIM" one.

I was never able to get the "AIM" module to work which I would like to address after getting this resolved.

I did some transaction testing myself and seemed to get some emails but not others and in this case, all showed up in the database when I logged into the Admin.

I did the upgrade to 1.3.0.2 and tested and it seems to be working as of now.

I really appreciate the quick and helpful response on this.

[briandmiller]

I am getting this error again when I go to confirm checkout:

1264 Out of range value adjusted for column 'delivery_address_format_id' at row 1
in:
[INSERT INTO orders

at https://secure.authorize.net/gateway/transact.dll

The transaction still goes through to Authorize.net

The item remains im the shopping cart

[DrByte]

how much control do you have over your MySQL ?
Can you turn off the STRICT_TRANS_TABLES setting?

[DrByte]

I guess the other problem is ... why are you getting a blank for the address-format?

To fudge your way around the error, you could edit includes/classes/order.php
around line 568 you have:

                            'delivery_address_format_id' => $this->delivery['format_id'], 

change it to:

                            'delivery_address_format_id' => (int)$this->delivery['format_id'], 

That is only a very weak bandage though... and will likely just pacify until the next problem shortly thereafter...