Decimal data not stored correctly in database by doctrine
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
Within one of my Symfony applications I encountered a strange behavior of the doctrine ODM. What I'm trying to do is simply saving decimal typed data to our Informix database. Whenever I try to do so everything behind the decimal separator is cropped.
I tried several ways of assigning data such as:
- $position->setFrpProz(1.2345);
- $position->setFrpProz("1.2345");
- $position->setFrpProz("1,2345");
The result in the database is always: 1.0000
This is the yml for the entity:
frpProz:
type: decimal
nullable: true
precision: 10
scale: 4
column: frp_proz
Within Informix the database field is also defined as Decimal(10,4).
I already tried the Doctrine EchoSQLLogger with following results (shortend):
"START TRANSACTION"
UPDATE st_frb_mpos SET frp_proz = ?, [...] WHERE [...]
array(15) {
[0]=>
string(6) "1.2345"
[...]
}
array(15) {
[0]=>
string(7) "decimal"
[...]
}
"COMMIT"
"okay"
I really don't know how to solve this. I already tried to upgrade my application from symfony 2.8.? to 3.4.15 - no difference in this topic.
Thanks for your help!
php symfony doctrine-orm informix
add a comment |
Within one of my Symfony applications I encountered a strange behavior of the doctrine ODM. What I'm trying to do is simply saving decimal typed data to our Informix database. Whenever I try to do so everything behind the decimal separator is cropped.
I tried several ways of assigning data such as:
- $position->setFrpProz(1.2345);
- $position->setFrpProz("1.2345");
- $position->setFrpProz("1,2345");
The result in the database is always: 1.0000
This is the yml for the entity:
frpProz:
type: decimal
nullable: true
precision: 10
scale: 4
column: frp_proz
Within Informix the database field is also defined as Decimal(10,4).
I already tried the Doctrine EchoSQLLogger with following results (shortend):
"START TRANSACTION"
UPDATE st_frb_mpos SET frp_proz = ?, [...] WHERE [...]
array(15) {
[0]=>
string(6) "1.2345"
[...]
}
array(15) {
[0]=>
string(7) "decimal"
[...]
}
"COMMIT"
"okay"
I really don't know how to solve this. I already tried to upgrade my application from symfony 2.8.? to 3.4.15 - no difference in this topic.
Thanks for your help!
php symfony doctrine-orm informix
Do you have the ability to access the database usingdbaccess
? If so, does it report truncated values or does it show (2?) decimal places? Passing a string like you seem to be doing normally works. We may have to try debugging withsqliprint
in due course, but that’s a low-level last resort.
– Jonathan Leffler
Sep 12 '18 at 9:45
I made a quick query usingdbaccess
the result is as expectedfrp_proz 12,7000
. I'm usually using NetBeans to access the database. If I'm updating rows using the IDE all decimal digits are stored correctly. Even my Symfony-App shows all decimal digits - it just does not store them.
– Torben
Sep 12 '18 at 10:08
Are you saying that when you usedbaccess
to query data entered by Symfony, you don’t get the decimal places, but when you query data entered viadbaccess
, you do? Or do you get the decimal places on query regardless of how the data was inserted, but Symfony doesn’t show the decimal places?
– Jonathan Leffler
Sep 12 '18 at 10:12
The decimal places are displayed in Symfony anddbaccess
if they are entered bydbaccess
or an 4GL application running on that database. Whenever I enter data using Symfony the decimal places are all zero no matter if I usedbaccess
or Symfony to display the data.
– Torben
Sep 12 '18 at 11:57
add a comment |
Within one of my Symfony applications I encountered a strange behavior of the doctrine ODM. What I'm trying to do is simply saving decimal typed data to our Informix database. Whenever I try to do so everything behind the decimal separator is cropped.
I tried several ways of assigning data such as:
- $position->setFrpProz(1.2345);
- $position->setFrpProz("1.2345");
- $position->setFrpProz("1,2345");
The result in the database is always: 1.0000
This is the yml for the entity:
frpProz:
type: decimal
nullable: true
precision: 10
scale: 4
column: frp_proz
Within Informix the database field is also defined as Decimal(10,4).
I already tried the Doctrine EchoSQLLogger with following results (shortend):
"START TRANSACTION"
UPDATE st_frb_mpos SET frp_proz = ?, [...] WHERE [...]
array(15) {
[0]=>
string(6) "1.2345"
[...]
}
array(15) {
[0]=>
string(7) "decimal"
[...]
}
"COMMIT"
"okay"
I really don't know how to solve this. I already tried to upgrade my application from symfony 2.8.? to 3.4.15 - no difference in this topic.
Thanks for your help!
php symfony doctrine-orm informix
Within one of my Symfony applications I encountered a strange behavior of the doctrine ODM. What I'm trying to do is simply saving decimal typed data to our Informix database. Whenever I try to do so everything behind the decimal separator is cropped.
I tried several ways of assigning data such as:
- $position->setFrpProz(1.2345);
- $position->setFrpProz("1.2345");
- $position->setFrpProz("1,2345");
The result in the database is always: 1.0000
This is the yml for the entity:
frpProz:
type: decimal
nullable: true
precision: 10
scale: 4
column: frp_proz
Within Informix the database field is also defined as Decimal(10,4).
I already tried the Doctrine EchoSQLLogger with following results (shortend):
"START TRANSACTION"
UPDATE st_frb_mpos SET frp_proz = ?, [...] WHERE [...]
array(15) {
[0]=>
string(6) "1.2345"
[...]
}
array(15) {
[0]=>
string(7) "decimal"
[...]
}
"COMMIT"
"okay"
I really don't know how to solve this. I already tried to upgrade my application from symfony 2.8.? to 3.4.15 - no difference in this topic.
Thanks for your help!
php symfony doctrine-orm informix
php symfony doctrine-orm informix
asked Sep 12 '18 at 7:56
TorbenTorben
61
61
Do you have the ability to access the database usingdbaccess
? If so, does it report truncated values or does it show (2?) decimal places? Passing a string like you seem to be doing normally works. We may have to try debugging withsqliprint
in due course, but that’s a low-level last resort.
– Jonathan Leffler
Sep 12 '18 at 9:45
I made a quick query usingdbaccess
the result is as expectedfrp_proz 12,7000
. I'm usually using NetBeans to access the database. If I'm updating rows using the IDE all decimal digits are stored correctly. Even my Symfony-App shows all decimal digits - it just does not store them.
– Torben
Sep 12 '18 at 10:08
Are you saying that when you usedbaccess
to query data entered by Symfony, you don’t get the decimal places, but when you query data entered viadbaccess
, you do? Or do you get the decimal places on query regardless of how the data was inserted, but Symfony doesn’t show the decimal places?
– Jonathan Leffler
Sep 12 '18 at 10:12
The decimal places are displayed in Symfony anddbaccess
if they are entered bydbaccess
or an 4GL application running on that database. Whenever I enter data using Symfony the decimal places are all zero no matter if I usedbaccess
or Symfony to display the data.
– Torben
Sep 12 '18 at 11:57
add a comment |
Do you have the ability to access the database usingdbaccess
? If so, does it report truncated values or does it show (2?) decimal places? Passing a string like you seem to be doing normally works. We may have to try debugging withsqliprint
in due course, but that’s a low-level last resort.
– Jonathan Leffler
Sep 12 '18 at 9:45
I made a quick query usingdbaccess
the result is as expectedfrp_proz 12,7000
. I'm usually using NetBeans to access the database. If I'm updating rows using the IDE all decimal digits are stored correctly. Even my Symfony-App shows all decimal digits - it just does not store them.
– Torben
Sep 12 '18 at 10:08
Are you saying that when you usedbaccess
to query data entered by Symfony, you don’t get the decimal places, but when you query data entered viadbaccess
, you do? Or do you get the decimal places on query regardless of how the data was inserted, but Symfony doesn’t show the decimal places?
– Jonathan Leffler
Sep 12 '18 at 10:12
The decimal places are displayed in Symfony anddbaccess
if they are entered bydbaccess
or an 4GL application running on that database. Whenever I enter data using Symfony the decimal places are all zero no matter if I usedbaccess
or Symfony to display the data.
– Torben
Sep 12 '18 at 11:57
Do you have the ability to access the database using
dbaccess
? If so, does it report truncated values or does it show (2?) decimal places? Passing a string like you seem to be doing normally works. We may have to try debugging with sqliprint
in due course, but that’s a low-level last resort.– Jonathan Leffler
Sep 12 '18 at 9:45
Do you have the ability to access the database using
dbaccess
? If so, does it report truncated values or does it show (2?) decimal places? Passing a string like you seem to be doing normally works. We may have to try debugging with sqliprint
in due course, but that’s a low-level last resort.– Jonathan Leffler
Sep 12 '18 at 9:45
I made a quick query using
dbaccess
the result is as expected frp_proz 12,7000
. I'm usually using NetBeans to access the database. If I'm updating rows using the IDE all decimal digits are stored correctly. Even my Symfony-App shows all decimal digits - it just does not store them.– Torben
Sep 12 '18 at 10:08
I made a quick query using
dbaccess
the result is as expected frp_proz 12,7000
. I'm usually using NetBeans to access the database. If I'm updating rows using the IDE all decimal digits are stored correctly. Even my Symfony-App shows all decimal digits - it just does not store them.– Torben
Sep 12 '18 at 10:08
Are you saying that when you use
dbaccess
to query data entered by Symfony, you don’t get the decimal places, but when you query data entered via dbaccess
, you do? Or do you get the decimal places on query regardless of how the data was inserted, but Symfony doesn’t show the decimal places?– Jonathan Leffler
Sep 12 '18 at 10:12
Are you saying that when you use
dbaccess
to query data entered by Symfony, you don’t get the decimal places, but when you query data entered via dbaccess
, you do? Or do you get the decimal places on query regardless of how the data was inserted, but Symfony doesn’t show the decimal places?– Jonathan Leffler
Sep 12 '18 at 10:12
The decimal places are displayed in Symfony and
dbaccess
if they are entered by dbaccess
or an 4GL application running on that database. Whenever I enter data using Symfony the decimal places are all zero no matter if I use dbaccess
or Symfony to display the data.– Torben
Sep 12 '18 at 11:57
The decimal places are displayed in Symfony and
dbaccess
if they are entered by dbaccess
or an 4GL application running on that database. Whenever I enter data using Symfony the decimal places are all zero no matter if I use dbaccess
or Symfony to display the data.– Torben
Sep 12 '18 at 11:57
add a comment |
2 Answers
2
active
oldest
votes
you are misunderstanding the meaning of scale.
Taken from the mysql docs.
The precision represents the number of significant digits that are stored for values, and the scale represents the number of digits that can be stored following the decimal point.
Because you have specified 10,4 the database is only storing 4 decimal places to the right of the point.
Precision is the total amount of digits to be stored. So 10,4 would allow you to store values such as 123456.7890
Hense any value you store will be cropped to 4 decimal places.
1
You are right, but I'm not mixing anything up. The precision is 10 and the scale is 4. So the number 1.2345 should be stored als 1.2345 and not 1.0000 Moreover, everything up to 999999.9999 should be saved just fine
– Torben
Sep 12 '18 at 8:41
add a comment |
Although in Informix you defined the receiving column as DECIMAL(10,4), its acting like you defined it as DECIMAL (10,0) and rounding 1.2345 to 1.0000, so maybe Symfony rounded it to 1.0000 before sending it to Informix?.. That's my suspicion of what's happening because its showing the 4 decimal zero's in Informix, which is a valid value for the precision/scale you defined. So I suggest you research your Symfony frp_proz NumberType field options, such as scale and rounding_mode, to see if the number is being transformed in Symfony.
https://symfony.com/doc/current/reference/forms/types/number.html
Have you experimented casting it to CHAR before sending to Informix, or defining the Informix column as a FLOAT datatype to see the result?
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52290202%2fdecimal-data-not-stored-correctly-in-database-by-doctrine%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
you are misunderstanding the meaning of scale.
Taken from the mysql docs.
The precision represents the number of significant digits that are stored for values, and the scale represents the number of digits that can be stored following the decimal point.
Because you have specified 10,4 the database is only storing 4 decimal places to the right of the point.
Precision is the total amount of digits to be stored. So 10,4 would allow you to store values such as 123456.7890
Hense any value you store will be cropped to 4 decimal places.
1
You are right, but I'm not mixing anything up. The precision is 10 and the scale is 4. So the number 1.2345 should be stored als 1.2345 and not 1.0000 Moreover, everything up to 999999.9999 should be saved just fine
– Torben
Sep 12 '18 at 8:41
add a comment |
you are misunderstanding the meaning of scale.
Taken from the mysql docs.
The precision represents the number of significant digits that are stored for values, and the scale represents the number of digits that can be stored following the decimal point.
Because you have specified 10,4 the database is only storing 4 decimal places to the right of the point.
Precision is the total amount of digits to be stored. So 10,4 would allow you to store values such as 123456.7890
Hense any value you store will be cropped to 4 decimal places.
1
You are right, but I'm not mixing anything up. The precision is 10 and the scale is 4. So the number 1.2345 should be stored als 1.2345 and not 1.0000 Moreover, everything up to 999999.9999 should be saved just fine
– Torben
Sep 12 '18 at 8:41
add a comment |
you are misunderstanding the meaning of scale.
Taken from the mysql docs.
The precision represents the number of significant digits that are stored for values, and the scale represents the number of digits that can be stored following the decimal point.
Because you have specified 10,4 the database is only storing 4 decimal places to the right of the point.
Precision is the total amount of digits to be stored. So 10,4 would allow you to store values such as 123456.7890
Hense any value you store will be cropped to 4 decimal places.
you are misunderstanding the meaning of scale.
Taken from the mysql docs.
The precision represents the number of significant digits that are stored for values, and the scale represents the number of digits that can be stored following the decimal point.
Because you have specified 10,4 the database is only storing 4 decimal places to the right of the point.
Precision is the total amount of digits to be stored. So 10,4 would allow you to store values such as 123456.7890
Hense any value you store will be cropped to 4 decimal places.
answered Sep 12 '18 at 8:04
DevDonkeyDevDonkey
4,16722135
4,16722135
1
You are right, but I'm not mixing anything up. The precision is 10 and the scale is 4. So the number 1.2345 should be stored als 1.2345 and not 1.0000 Moreover, everything up to 999999.9999 should be saved just fine
– Torben
Sep 12 '18 at 8:41
add a comment |
1
You are right, but I'm not mixing anything up. The precision is 10 and the scale is 4. So the number 1.2345 should be stored als 1.2345 and not 1.0000 Moreover, everything up to 999999.9999 should be saved just fine
– Torben
Sep 12 '18 at 8:41
1
1
You are right, but I'm not mixing anything up. The precision is 10 and the scale is 4. So the number 1.2345 should be stored als 1.2345 and not 1.0000 Moreover, everything up to 999999.9999 should be saved just fine
– Torben
Sep 12 '18 at 8:41
You are right, but I'm not mixing anything up. The precision is 10 and the scale is 4. So the number 1.2345 should be stored als 1.2345 and not 1.0000 Moreover, everything up to 999999.9999 should be saved just fine
– Torben
Sep 12 '18 at 8:41
add a comment |
Although in Informix you defined the receiving column as DECIMAL(10,4), its acting like you defined it as DECIMAL (10,0) and rounding 1.2345 to 1.0000, so maybe Symfony rounded it to 1.0000 before sending it to Informix?.. That's my suspicion of what's happening because its showing the 4 decimal zero's in Informix, which is a valid value for the precision/scale you defined. So I suggest you research your Symfony frp_proz NumberType field options, such as scale and rounding_mode, to see if the number is being transformed in Symfony.
https://symfony.com/doc/current/reference/forms/types/number.html
Have you experimented casting it to CHAR before sending to Informix, or defining the Informix column as a FLOAT datatype to see the result?
add a comment |
Although in Informix you defined the receiving column as DECIMAL(10,4), its acting like you defined it as DECIMAL (10,0) and rounding 1.2345 to 1.0000, so maybe Symfony rounded it to 1.0000 before sending it to Informix?.. That's my suspicion of what's happening because its showing the 4 decimal zero's in Informix, which is a valid value for the precision/scale you defined. So I suggest you research your Symfony frp_proz NumberType field options, such as scale and rounding_mode, to see if the number is being transformed in Symfony.
https://symfony.com/doc/current/reference/forms/types/number.html
Have you experimented casting it to CHAR before sending to Informix, or defining the Informix column as a FLOAT datatype to see the result?
add a comment |
Although in Informix you defined the receiving column as DECIMAL(10,4), its acting like you defined it as DECIMAL (10,0) and rounding 1.2345 to 1.0000, so maybe Symfony rounded it to 1.0000 before sending it to Informix?.. That's my suspicion of what's happening because its showing the 4 decimal zero's in Informix, which is a valid value for the precision/scale you defined. So I suggest you research your Symfony frp_proz NumberType field options, such as scale and rounding_mode, to see if the number is being transformed in Symfony.
https://symfony.com/doc/current/reference/forms/types/number.html
Have you experimented casting it to CHAR before sending to Informix, or defining the Informix column as a FLOAT datatype to see the result?
Although in Informix you defined the receiving column as DECIMAL(10,4), its acting like you defined it as DECIMAL (10,0) and rounding 1.2345 to 1.0000, so maybe Symfony rounded it to 1.0000 before sending it to Informix?.. That's my suspicion of what's happening because its showing the 4 decimal zero's in Informix, which is a valid value for the precision/scale you defined. So I suggest you research your Symfony frp_proz NumberType field options, such as scale and rounding_mode, to see if the number is being transformed in Symfony.
https://symfony.com/doc/current/reference/forms/types/number.html
Have you experimented casting it to CHAR before sending to Informix, or defining the Informix column as a FLOAT datatype to see the result?
edited Nov 25 '18 at 2:39
answered Nov 25 '18 at 1:12
Frank R.Frank R.
1,24722160
1,24722160
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52290202%2fdecimal-data-not-stored-correctly-in-database-by-doctrine%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Do you have the ability to access the database using
dbaccess
? If so, does it report truncated values or does it show (2?) decimal places? Passing a string like you seem to be doing normally works. We may have to try debugging withsqliprint
in due course, but that’s a low-level last resort.– Jonathan Leffler
Sep 12 '18 at 9:45
I made a quick query using
dbaccess
the result is as expectedfrp_proz 12,7000
. I'm usually using NetBeans to access the database. If I'm updating rows using the IDE all decimal digits are stored correctly. Even my Symfony-App shows all decimal digits - it just does not store them.– Torben
Sep 12 '18 at 10:08
Are you saying that when you use
dbaccess
to query data entered by Symfony, you don’t get the decimal places, but when you query data entered viadbaccess
, you do? Or do you get the decimal places on query regardless of how the data was inserted, but Symfony doesn’t show the decimal places?– Jonathan Leffler
Sep 12 '18 at 10:12
The decimal places are displayed in Symfony and
dbaccess
if they are entered bydbaccess
or an 4GL application running on that database. Whenever I enter data using Symfony the decimal places are all zero no matter if I usedbaccess
or Symfony to display the data.– Torben
Sep 12 '18 at 11:57