I am having some difficulties about storing integer data with commas, I have prices, which is like 4,600 So I need to store it with commas but when I try to send it as Integer it cut after first number. I tried to change column type. BigInt or Double but it doesn't effect any. Any possible way to do that?
Also tried to change comma to dot "." but with this, mysql delete the "0" at last... I don't know why...
Prices
------
4,500
2,300
1,500
Because you're using a comma, MySQL most likely interprets the number as two fields, separated by the comma. For example:
Prices,Unspecified
------,-----------
4 ,500
2 ,300
1 ,500
In the numbers in question: If the comma is a thousands separator, remove it (via String replace) before trying to store the number. If it's a decimal point, replace it with a period (via String replace) and store it as a DOUBLE (or DECIMAL if you need high accuracy for large numbers).
If you want to display the number with a comma, use String formatting (possibly a number-formatting function other than String.format() or sprintf()) after retrieving the value from the database.
If you want to be able to do calculations using SQL queries with those numbers, then you need to store the price either use the DECIMAL type or use integer types and multiply the number by e.g. 1000 before saving.
Double or any other floating point representation of numbers are not suitable for price calculations/storage.
If you use DECIMAL need to convert the number form your local format 4,5000 to the format the database expects when you store it in the database, and convert it back to the local format when you retrieve your data.
If you store it as string then you can keep your local format but that's the worst solution, and should never be used.
Related
Please look at my screenshots and help me to understand what I am missing.
What datatype should I choose for these columns in MYSQL? I keep getting mistakes in decimal datatype columns. I chose decimаl12,3 because no columns(revenue, product&purchase price) with currency have more than 12 digits in total, 9 before and 3 after the decimal point. Could someone help me to understand what data type to choose with examples?
if we have an integer number e.g. 85192 we choose int?
for currency we choose the decimal, right? then what have I done wrong that I keep getting errors? 0 records imported.
if we have a combination of numbers and letters or just letters then we choose varchar? and varchаr1 equals 1 character, eg. apple32 = 7 characters, therefore vаrchar7?
turning to decimal, 12,464.87 in total 7 digits, 5 before and 2 after the decimal point, hence mysql decimаl7,2 should be enough, right? or would it be better to put decimаl10,3 with a margin so to say.
excel
mysql
data
$1,000.00 contains two characters that cannot be part of a numeric literal: the dollar sign and the comma that is used as a thousands separator.
Find a way to change '$1,000.00' to '1000.00' in the input file. Then, the load will succeed.
Alternatively, create an intermediate table where product_price is a VARCHAR(32), load into that, and then:
INSERT INTO target_table
SELECT
other_col1
,other_col2
, ....
,CAST(REPLACE(REPLACE(product_price,',',''),'$','') AS DECIMAL(15,2)
,other_col_n
,...
FROM staging_table;
You don't need an intermediate table. When doing LOAD DATA, put and columns into #variables; then use a SET to convert as needed:
LOAD DATA
...
col1, col2, #price, ...,
SET price = CAST(REPLACE(REPLACE(product_price,',',''),'$','') AS DECIMAL(15,2))
Dates need to be like this: "2022-07-25 22:02:22". Either change what Excel is delivering, or use STR_TO_DATE(...) in the SET.
I have a column from my .csv file coming in with values as 1754625.24 etc,. where as we have to save it as integer in our database. So am trying to split number with '.' and divide second part with 1000 (24/1000) as i want 3 digit number.
so i get 0.024. But i am having issues storing/preserving that value as a decimal.
I tried (DT_DECIMAL,3) conversion but i get result as '0'.
My idea is to then append '024' part to original first part. So my final result should look like 1754625024
Please help
I am not convinced why would you store 1754625.24 as 1754625024 when storing it as int.
But still for your case , we can use a derived column task and
use Replace command on the source column of csv. E.g.
Replace('1754625.24','.',0)
We have a field in a query that should be left-padded with zeroes if it is too short, and we accomplish this using the Format() function. However, there are some values that produce bizarre results.
Format("14425112-8","00000000-00")
Returns the value "00019330-78"
For most inputs, the string gets formatted as expected, 8 digits, hyphen, two digits. But in a few rare cases, the value is modified. Is this repeatable for anyone else? Does anyone have an explanation?
Thanks for your help.
This is an example of access trying to be too helpful. It looks like it is interpreting these values as dates, but since you didn't use any date indicators in the format e.g: (dd,mm,yyyy), it converted 1-1 to a date, and then tried to display it in decimal form:
debug.print Format("1-1","000000-00")
returns 000427-36 which is the decimal value 42736 which, if you convert to a date, becomes 1/1/2017. This is what access interpreted "1-1" as.
it seems that access has reserved the - character as symbolizing a date format, despite what their website says. This function is only useful for formatting actual dates, or numeric values, such as prices. If you are set on using the format function, you will have to change you separator to a decimal point, which apparently is the only character that will get you what you want with the leading and trailing zeros.
Otherwise, you may have to build your own function for this.
You cannot format a string like a number this way. Try this:
PaddedNumber = Right(String(8, "0") & "14425112-8", 10)
I'm storing some double values on mysql table for products' price.
Column type is : double
Length is :8
Decimal is : 2
Is it valid or useful? Also If I set decimals to "0" I can still store decimals. Which approach is better?
Also default, when I pass values to mysql, decimal seperator is comma ",". (PHP pass doubles like 123.45 so on php side seperator is point "." How can I enforce to "." on mysql side)? As far as I know it is a SQL standart so I can't.
I have set my MySQL field table data type to the decimal because from what I have read, I would be able to store the price with commas/dots in the decimal data type fields... The problem is that whenever I store any data with the comma or dot, MySQL is rounding it automatically up or down. Eg. When I'm executing the following query:
UPDATE table SET field = 114.21 WHERE id = 1;
Then field is set, but the value is rounded to 114, instead of displaying the data I set in the query (114.21) - is there any solution for that? Or I should just use other data type?
AFAIK the dot is the standard notation for decimal values. Using Commas may trigger SQL parse errors or may go unnoticed if the syntactical context allows for a comma to be there.
How did you define the precision of the DECIMAL column?
If it is DECIMAL(10, 2) it will have a total of 10 numbers of which 2 are decimal values (with 2 decimal rounding meaning that 10.215 is saved as 10.22 and 10.214 becomes 10.21).
If it is DECIMAL(10) it will not have any decimal values and be rounded to an integer.
If you use FLOAT or DOUBLE PRECISION you don't have to specify the number of decimal values but it has its own flaws.
As Mihai mentioned you need to define the proper precision for the decimal type, e.g. DECIMAL(10,2) for two decimal places.
When inserting a decimal value mySQL will round.
From the docs:
For inserts into a DECIMAL or integer column, the target is an exact data type, so rounding uses “round half away from zero,” regardless of whether the value to be inserted is exact or approximate.
See http://dev.mysql.com/doc/refman/5.0/en/precision-math-rounding.html for details.
Well before I have also an issue regarding on what to use on my numbers with decimal points. But problem solved by using DOUBLE(10,2) as my DATATYPE, and it shows the exact number on the database when you save it. Hope it will help.