Can anyone suggest the way to implement this
Declare #x decimal(22,10)='234323154322.6787654321'
Declare #y decimal(20,10)=#x;
Currently giving error:
Arithmetic overflow error converting numeric to data type numeric.
Are you looking for this:
Declare #x decimal(22,10)='234323154322.6787654321'
Declare #y decimal(20,10)=#x/100;
SELECT #x,#y
Related
I refer the following number with datatype bigInt.
DECLARE #Number Bigint = '269687584'
When I convert the datatype to Varbinary(4), it returns 0x10131B20.
But when I calculate the length of the Varbinary data, it returns only 3.
I didn't know exact what wrong.
In SQL Server database, I want to write an query to convert Bigint to
Varbinary(4), but is converted as only as Varbinary(3).
Here is what I have tried:
DECLARE #Number BIGINT = '269687584'
SELECT
#Number,
CONVERT(VARBINARY(4), #Number),
LEN(CONVERT(VARBINARY(4), #Number))
Use DATALENGTH instead:
DECLARE #Number BIGINT ='269687584'
SELECT #Number, CONVERT(VARBINARY(4), #Number), DATALENGTH(CONVERT(VARBINARY(4), #Number))
There is nothing wrong. You should check lenght using datalength:
DECLARE #Number Bigint ='269687584'
SELECT #Number, CAST(#Number AS Varbinary(4)), DATALENGTH(CAST(#Number AS Varbinary(4)))
declare #Commission decimal(18,2)
select #Commission=percentage from Commission
declare #qry varchar(Max)
set #qry='select 5 +'+#Commission +''
EXEC(#qry)
Here
The Error converting data type varchar to numeric.
Don't pass values into dynamic SQL as strings. Instead, learn to use sp_executesql:
declare #Commission decimal(18, 2);
select #Commission = percentage
from Commission;
declare #qry varchar(Max);
set #qry='select 5 + #Commission';
exec sp_executesql #qry, 'N#Commission decimal(18, 2)', #Commission=#Commission;
SQL Server's implicit conversion rules makes it attempt to implicitly convert your varchar to decimal. You need to explicitly convert the decimal to varchar:
set #qry='select 5 +'+ CAST(#FranchiseeCommission as varchar(20))
set #qry='select 5 +'+convert(nvarchar(max),#FranchiseeCommission)+''
Try it like this:
SET #qry='select 5 +'+CAST(#FranchiseeCommission AS varchar(30))+''
Since your variable is a decimal, you have to cast it as varchar in order to combine it with your string.
There is always concat() if 2012+
set #qry=concat('select 5 +',#Commission)
In the following query
declare #a float(23)
declare #b float(23)
declare #c float(53)
set #a = 123456789012.1234
set #b = 1234567.12345678
set #c = #a * #b
select #c
select LTRIM(STR((#c),32,12))
declare #x decimal(16,4)
declare #y decimal(16,8)
declare #z decimal (32,12)
set #x = 123456789012.1234
set #y = 1234567.12345678
set #z = #x * #y
select #z
I get answers as
1.52415693411713E+17
152415693411713020.000000000000
152415692881907790.143935926652
From the above answers the third answer is the correct one. Is this the reason why float data type is called Approximate Numeric Data Type
Or am I doing something fundamentally wrong.
BTW this is due to a problem I have with legacy system wherein I have to use float as storage data type, at the same time in there should not be loss of precision while calculation.
Please suggest alternatives, or an explanation.
Float is accurate to 15 significant figures only (in SQL Server).
This is demonstrated by 1.52415693411713 E+17 where 1.52415693411713 (15 digits) is as accurate as you'll get. The final 020... after 152415693411713 with STR is made up is the resolution of floating point
To keep precision, don't use float. It is that simple. CAST to decimal if you want for calculation, but if you CAST back to float you are limited to 15 digits
See "What Every Computer Scientist Should Know About Floating-Point Arithmetic"
The last answer
152415692881907790.143935926652
is providing scale up to 12 decimal places because you have declared #z accordingly.
declare #z decimal (32,12)
The second parameter in this declaration is scale which is set to 12.
More on the this can be found at http://msdn.microsoft.com/en-us/library/ms187746.aspx
Problem not with float Data type.
Problem is with using float(23).
This data type has a capacity of holding 8 significant digits, not 15 as float(53).
And that's exactly how many correct digits you've got in the output.
Calculation of 2 float(23) numbers is done with float(23) precision, and only afterwards converted to float(53), which is absolutely useless and misleading.
Fix the initial declarations of #a and #b and the problem will disappear.
Always check what is the value to have actually assigned to a variable:
declare #a float(23)
declare #b float(23)
declare #c float(23)
set #a = 123456789012.1234
set #b = 1234567.12345678
SET #c = #a * #b
select #a, #b, #c
GO
declare #a float
declare #b float
declare #c float
set #a = 123456789012.1234
set #b = 1234567.12345678
SET #c = #a * #b
select #a, #b, #c
GO
The outputs of the SELECTs:
1.234568E+11 1234567 1.524157E+17
123456789012.123 1234567.12345678 1.52415692881908E+17
P.S. Operations of 2nd level (multiplication, division) and upper on decimal values use float point computing, so they cannot be any more precise than same operations on FLOAT values, assuming the same level of depth used for both types.
I need to do some math with SQL Server GUIDs in a trigger and I'm having difficulty figuring out how to convert a uniqueidentifier to a numeric(38,0).
One potential problem: my understand is that both of these datatypes are 16-byte "integers". If I'm wrong here, please correct me.
Otherwise, how would I go about this conversion? I've tried CAST and CONVERT and keep getting Explicit conversion from data type uniqueidentifier to numeric is not allowed. as an error message whenever I try. I'd really like to not have to parse each character and do hex math in a UDF to do this.
Is this possible?
Here's my script to repro this real quick:
DECLARE #guid uniqueidentifier
SET #guid = NEWID()
DECLARE #a numeric(38,0)
SET #a = 2
PRINT CAST(#guid AS numeric(38,0)) -- fails
PRINT #guid / #a -- also fails
Unfortunately, I haven't stumbled on a conversion from a hexadecimal value in a VARCHAR to a NUMERIC short of looping through one digit at a time.
declare #GUID as UniqueIdentifier = NewId()
declare #Binary as VarBinary(64) = #GUID
declare #String as VarChar(64) = Convert( VarChar(64), #Binary, 2 )
select #GUID as 'GUID', #Binary as 'Binary', #String as 'String'
This is a follow up to my previous question, in t-sql
SELECT SCOPE_IDENTITY()
returns a BIGINT, I did the following to get it to return an INT:
DECLARE #X INT
INSERT ...
SELECT #X = SCOPE_IDENTITY()
-- if i don't include the line below, it will return a BIGINT
SELECT #X
Why does it return a BIGINT unless I do SELECT #X at the end?
p.s. turns out
SELECT #X = SCOPE_IDENTITY()
doesn't return anything, it just sets #x
The statement
SELECT #X = SCOPE_IDENTITY()
is an assignment statement. As in most programming languages, an assignment statement is executed by first evaluating the right hand side. In this case the right hand side evaluates to a bigint. When the value of #X gets the resulting bigint, there is an implicit type conversion, because #X is a different type (int) than the value it's receiving.
SQL is a typed language, and the type of an expression (such as SCOPE_IDENTITY() here) depends on the expression, not on what happens to the expression's value after evaluation.
Analogy:
DECLARE #i INT;
SET #i = 3.2 + 0.2;
You wouldn't suggest that 3.2 + 0.2 is an integer, would you? It's 3.4, a decimal. Only because of the assignment is there an implicit conversion to INT.
There's no magic in most programming languages.
SELECT SCOPE_IDENTITY()
returns a BIGINT as you have seen
SELECT #X = SCOPE_IDENTITY()
returns BIGINT and casts it into INT variable #X
So you are returning BIGINT SCOPE_IDENTITY and also concurrently casting it to INT and setting that result to #X.
Returning #X returns the INT result.
Just some interesting reading on the subject.
SQL Server 7.0 Books Online also
stated: "It is recommended that SET
#local_variable be used for variable
assignment rather than SELECT
#local_variable."