I am inputting data into my holding database "Premium_DB" in snowflake. But I noticed an omission in the numeric columns. For some reason, snowflake is removing the decimals in the holding database.
For example:
This is my current result
(Selected column) (Input Column)
"GrossPremium" "Gross_Premium"
30.52 30
4.1 4
Expected Result:
(Selected column) (Input Column)
"GrossPremium" "Gross_Premium"
30.52 30.52
4.1 4.1
Is there any way to archive this? Thank you so much for your help.
set Reference_Org_Var = 'EXCHANGE_BEN';
set Load_Date_Var = current_date();
insert into PREMIUM_DB(Issue_State, Gross_Premium, Commissions, Premium_Tax, Carrier_Fee, Admin_Fee,
Net_Premium, REPORT_DATE, FileRecdDate, Reference_Org, LoadDt
)
select STATE, GROSSPREMIUM, COMMISSION, PREMIUMTAX, CARRIERFEE, ADMINISTRATOR,
NETPREMIUM, REPORT_DATE, FILERECDDATE, $Reference_Org_Var,
$Load_Date_Var
from EXCHANGE_BEN_PREM;
CREATE OR REPLACE TABLE PREMIUM_DB
(Reference_Org varchar,
Gross_Premium number,
Commissions number,
TPA_Fee number,
Premium_Tax number,
Carrier_Fee number,
Admin_Fee number,
Net_Premium number,
Report_Date date,
LoadDt date,
FileRecdDate date,
);
The key is the data type:
NUMBER
Precision - Total number of digits allowed.
Scale - Number of digits allowed to the right of the decimal point.
By default, precision is 38 and scale is 0 (i.e. NUMBER(38, 0))
I suggest changing: Gross_Premium number to Gross_Premium number(38, 2).
Details: https://docs.snowflake.com/en/sql-reference/data-types-numeric.html#data-types-for-fixed-point-numbers
Related
I have table with structure as follow :
Table1 (
id int NULL,
description varchar(50) null,
rate decimal(18,15) NULL
)
and when I test insert data into the table problem value like this :
insert into Table1 (id, description, rate)
values (1, 'My Room Upstair', 38397.0893181818)
and the error like this :
Msg 8115, Level 16, State 8, Line 1 Arithmetic overflow error
converting numeric to data type numeric.
But when I use Float data type the data inserted successful. But the rate value change to different value.
need advice please...
solution of decimal data type problem
The problem is that you are not using the decimal data type correctly.
The data type is defined like this decimal(a, b).
a is used to specify the amount of digits in the value. The default value is 18, but you can choose whatever number between 1, which is the minimum and 38, which is the maximum.
b is used for the amount of digits after the decimal point. The default value is 0 but you can specify choosing between the minimum and maximum, which are the same 1 and 38. b can only be specified if a is also specified. It needs to be equal or less than a.
In your example decimal(18,15), you can insert a number that is 18 digits long, 3 before and 15 after the decimal point. 38397.0893181818 has 5 digits before the decimal point, which is why you get the error. So if you need to add 38397.0893181818, you need decimal(15,10), since the number has 15 digits, 10 of which are after the decimal point.
The problem is that the decimal(a,b) parameters work according to what you need, a defines the number of total digits and b defines the number of digits of that total that will go after the decimal point.
https://learn.microsoft.com/es-es/sql/t-sql/data-types/decimal-and-numeric-transact-sql?view=sql-server-ver16
In my SQL class, I'm working with a table that is all VARCHAR. I'm trying to convert each column to a more correct data type.
For example. I have a column called Item_Cost that has a value like:
1.25000000000000000000
I tried to run this query:
ALTER TABLE <table>
ALTER COLUMN Item_Cost DECIMAL
This query does run successfully, but it turns it into 1 instead of 1.25.
How do I prevent the rounding?
Check out the documentation for the data type decimal. The type is defined by optional parameters p (precision) and s (scale). The latter determines the numbers to the right of the decimal point.
Extract from the documentation (I highlighted the important bit in bold):
s (scale)
The number of decimal digits that are stored to the right of
the decimal point. This number is subtracted from p to determine the
maximum number of digits to the left of the decimal point. Scale must
be a value from 0 through p, and can only be specified if precision is
specified. The default scale is 0 and so 0 <= s <= p. Maximum storage
sizes vary, based on the precision.
Defining a suitable precision and scale fixes your issue.
Sample data
create table MyData
(
Item_Cost nvarchar(100)
);
insert into MyData (Item_Cost) values ('1.25000000000000000000');
Solution
ALTER TABLE MyData Alter Column Item_Cost DECIMAL(10, 3);
Result
Item_Cost
---------
1.250
Fiddle
A table of financials has been provided to me with the following datatypes:
billed varchar 9
allowed varchar 9
paid varchar 7
with the following columns and values:
billed = 2555 allowed = 1051 paid = 951
I want to convert the varchar values (the whole column) to money or to some format where I'll have a $ sign and the number will have 2 decimal points instead of rounding up. I need the SUM to remain because I'm adding up values throughout the columns based on the date.
My Expected Results are:
BILLED
$2,554.67
ALLOWED
$1,050.75
PAID
$950.75
I have code that I've used, but I can't seem to format it correctly to be viewable in the post.`
Cast the values as numeric, do math with a function like sum, format as money and concatenate the $ symbol at the beginning.
Simplified example doing conversion:
select ('$' + FORMAT(CONVERT(MONEY, cast([allowed] as numeric(38,2))), '###,###.####')) as AllowedConversionExample
from dbo.payments
Simplified example with math using sum()
select
'$' + FORMAT(CONVERT(MONEY, sum(cast(V.Val as numeric(38,2)))), '###,###.####')
from (
select cast('1050.75' as varchar(9)) Val
union select cast('950.75' as varchar(9))
) V
In SQL Server, I have a query that returns a value of 177200. I need this value represented as 1772.00 as the last 2 digits are past the decimal. The query below is adding .00 to the end of the full value. I have no experience in this type of SQL statement. Any help would be appreciated.
SELECT
STR(SUM(ActualPrice), 10, 2) AS Total, Department
FROM
#DepartmentSalesData
GROUP BY
Department
The data type you're looking for is called numeric
SELECT CAST(SUM(ActualPrice) / 100.0 AS numeric(18, 2)) AS Total, ...
FROM ...
You're passing in a precision (18 in my example) and a scale 2 in my example, as requested by you.
What is the best datatype for holding percent values ranging from 0.00% to 100.00%?
Assuming two decimal places on your percentages, the data type you use depends on how you plan to store your percentages:
If you are going to store their fractional equivalent (e.g. 100.00% stored as 1.0000), I would store the data in a decimal(5,4) data type with a CHECK constraint that ensures that the values never exceed 1.0000 (assuming that is the cap) and never go below 0 (assuming that is the floor).
If you are going to store their face value (e.g. 100.00% is stored as 100.00), then you should use decimal(5,2) with an appropriate CHECK constraint.
Combined with a good column name, it makes it clear to other developers what the data is and how the data is stored in the column.
Hold as a decimal.
Add check constraints if you want to limit the range (e.g. between 0 to 100%; in some cases there may be valid reasons to go beyond 100% or potentially even into the negatives).
Treat value 1 as 100%, 0.5 as 50%, etc. This will allow any math operations to function as expected (i.e. as opposed to using value 100 as 100%).
Amend precision and scale as required (these are the two values in brackets columnName decimal(precision, scale). Precision says the total number of digits that can be held in the number, scale says how many of those are after the decimal place, so decimal(3,2) is a number which can be represented as #.##; decimal(5,3) would be ##.###.
decimal and numeric are essentially the same thing. However decimal is ANSI compliant, so always use that unless told otherwise (e.g. by your company's coding standards).
Example Scenarios
For your case (0.00% to 100.00%) you'd want decimal(5,4).
For the most common case (0% to 100%) you'd want decimal(3,2).
In both of the above, the check constraints would be the same
Example:
if object_id('Demo') is null
create table Demo
(
Id bigint not null identity(1,1) constraint pk_Demo primary key
, Name nvarchar(256) not null constraint uk_Demo unique
, SomePercentValue decimal(3,2) constraint chk_Demo_SomePercentValue check (SomePercentValue between 0 and 1)
, SomePrecisionPercentValue decimal(5,2) constraint chk_Demo_SomePrecisionPercentValue check (SomePrecisionPercentValue between 0 and 1)
)
Further Reading:
Decimal Scale & Precision: http://msdn.microsoft.com/en-us/library/aa258832%28SQL.80%29.aspx
0 to 1 vs 0 to 100: C#: Storing percentages, 50 or 0.50?
Decimal vs Numeric: Is there any difference between DECIMAL and NUMERIC in SQL Server?
I agree with Thomas and I would choose the DECIMAL(5,4) solution at least for WPF applications.
Have a look to the MSDN Numeric Format String to know why :
http://msdn.microsoft.com/en-us/library/dwhawy9k#PFormatString
The percent ("P") format specifier multiplies a number by 100 and converts it to a string that represents a percentage.
Then you would be able to use this in your XAML code:
DataFormatString="{}{0:P}"
If 2 decimal places is your level of precision, then a "smallint" would handle this in the smallest space (2-bytes). You store the percent multiplied by 100.
EDIT: The decimal type is probably a better match. Then you don't need to manually scale. It takes 5 bytes per value.
Use numeric(n,n) where n has enough resolution to round to 1.00. For instance:
declare #discount numeric(9,9)
, #quantity int
select #discount = 0.999999999
, #quantity = 10000
select convert(money, #discount * #quantity)