View Issue Details

IDProjectCategoryView StatusLast Update
0005774OXID eShop (all versions)1.03. Basket, checkout processpublic2023-11-27 16:44
ReporterFibreFoX Assigned To 
Status confirmedResolutionreopened 
Product Version4.8.5 / 5.1.5 
Summary0005774: oxuserbasketitems storing amount by char (should be double)
DescriptionThe table oxuserbasketitems is used for persisting the basket until the customer comes back or reloggs into his account, but if you enable non-integer amounts, that values aren't stored right
TagsDatabase, Product domain and basket rewrite
PHP VersionNot defined
Database VersionNot defined



2014-05-26 13:42

reporter   ~0009926

Reminder sent to: FibreFoX


Thank you a lot for submitting this issue, but for us is no clear which behaviors is incorrect. If it's still the issue - please give us more details about the case?

Best regards,


2014-05-26 14:33

reporter   ~0009927

The stored basket for users doesnt takes account for non-integer amounts like orderarticles does.

Enabled the setting "Allow fraction Quantities (e.g. 1.5) " (blAllowUnevenAmounts).

SQL queries:

CREATE TABLE `oxuserbasketitems` (
`OXAMOUNT` char(32) NOT NULL default '' COMMENT 'Amount',

CREATE TABLE `oxorderarticles` (
`OXAMOUNT` double NOT NULL default '0' COMMENT 'Amount',

the table oxuserbasketitems should be double instead of char.


2014-05-27 12:48

reporter   ~0009928

Generally DOUBLE type is not a recommended type for storing financial data. See:

The candidate type for storing basket data might be DECIMAL here. However when implementing that please do not forget its own repercussions (e.g. calculated result value 1.559 might be rounded to 1.55 instead of 1.56).


2014-05-28 20:14

reporter   ~0009931

No note why this is closed? -> reopen

the amount isn't holding "financial data". if oxuserbasketitems is switched to decimal, the oxorderarticles should be changed too (maybe other databases/models too).


2014-06-05 14:18

reporter   ~0009940

Reminder sent to: FibreFoX


As mention in previous note Double type is not a recommended type for this case. Char type currently is a risk free choice unless it affects the functionality in a negative way. Do you know any use cases where given type could cause any functionality problems?

Best regards


2014-06-05 14:53

reporter   ~0009942

Last edited: 2014-06-05 14:54


so if CHAR(32) is the right choice, it should be in oxorderarticles as well :) in that case oxuserbasketitems is the correct one. At least ONE database-table is wrong.