Order Confirmation Not Being Delivered

snifferdog:

Hi DrByte,

I think the database columns in question are integers (or other numeric types) rather than strings. MySQL appears not to accept an empty value for such columns in INSERT statements (you would think it would apply the default, would you not?). The error message when num_cart_items was missing from the POST was something like:

Invalid integer value: ''

(That's two adjacent single quotes there). Of course another solution would be to omit the column from the INSERT statement entirely if it is not preset in the POST. It's the empty value that trips up MySQL.

I'm only guessing here, but PayPal may have changed the contents of their IPN POST's. That would explain why this problem has suddenly started occurring. And / or it may be that this problem is specific to MySQL 5. MySQL is not my field of expertise.

Anyway, I hope that is all clear.yes, that's all data-type stuff. MySQL 4 and earlier were very forgiving if the supplied data (empty string for example) didn't match the datatype of the column it was being inserted into (ie: empty string would still be inserted as a 0 if it was for a numeric field). However, MySQL 5 is less forgiving (when operating in strict mode, which is the default (and desired) setting). The more correct way to deal with it is to enforce data types when doing the inserts to the database ... which is something that's been done for the v1.4.0 series currently under development.

snifferdog:

Good piece of software by the way, Zen Cart. You have left osCommerce far behind. Keep up the good work.

Thanks for the compliment and the feedback.

Sorry scatterjim, my solution only applies to PayPal IPN. But it wouldn't surprise me if there were similar problems in the Nochex APC module. The problem with scripts called on a postback is that there is no indication of failure.

Are you going to release some kind of patch, DrByte? It seems that a lot of other people have the same problem. What do you normally do in situations like this? Just leave the fix on the forum?

FWIW, Zen Cart seems to be running fine on MYSQL 5 (and PHP 5) on IIS apart from this one problem.

Oh yes, another thing I noticed. When the user 'Returns to Merchant', the order number displayed is often wrong. This is because the IPN processing takes place asynchronously and is often (infact, usually) not complete when the page is displayed.

I solve this in my own software by setting a flag in a table when the IPN POST is received. I 'stall' the page displaying the order number until this happens. I think what I will do in Zen Cart is simply not display the order number. Better that than display the wrong one.