Problem of checking out the cart; PHP error: 1264: Out of range value for column

[mc12345678]

Nice one, @mc12345678! Do you think that, perhaps, that field should be changed from a decimal format to simply float, given the "variety" of exchange rates?

That's a little hard to say at the moment without further review considering the precision/rounding issues with float. It seems primarily that if decimal is used that a sufficiently large bound be placed to handle the largest possible/expected conversion rate or a method to expand it if the need arises. It certainly is worth looking into if the change to 5,2 is successful.

[lat9]

That's a little hard to say at the moment without further review considering the precision/rounding issues with float. It seems primarily that if decimal is used that a sufficiently large bound be placed to handle the largest possible/expected conversion rate or a method to expand it if the need arises. It certainly is worth looking into if the change to 5,2 is successful.

Noting that chopping the number of significant digits to 2 will also produce rounding issues.

[mc12345678]

Noting that chopping the number of significant digits to 2 will also produce rounding issues.

If I remember correctly from looking over the exchange rate code set, the chopping occurs before storage and the database just sustains that cut-off number accurately. :)

[lat9]

If I remember correctly from looking over the exchange rate code set, the chopping occurs before storage and the database just sustains that cut-off number accurately. :)

That's not my point ... did you look at the number of significant digits in that exchange rate (119.34816139488) identified in post #14? While that value's not (currently) used for calculations, I was thinking that the more accurate a value stored, the better.

[mc12345678]

That's not my point ... did you look at the number of significant digits in that exchange rate (119.34816139488) identified in post #14? While that value's not (currently) used for calculations, I was thinking that the more accurate a value stored, the better.

I *do* agree that accuracy in such a number (exchange_rate) should be maintained to support its financial impact.

[jfigure.com]

Guys, I changed the data-type of "exchnage_rate" from decimal(4,2) to decimal(5,2). I will come back to you with the results of impact on my next order.
I do not receive any more error for the "payment_type" since its data-type was changed to varchar(64). Thank you, lat9.

[jfigure.com]

Dear zen-experts,

Now everything seems alright!!!

I received 3 orders since I changed the data-types of "payment_type" and "exchange_rate" and it seems that the customer could check out without a problem.

I really want to say THANK YOU for all of them who help me out this.

Best regards,

JFigure