Hallo,
as far as I remember the result of an arithmetic operation
in SQL Server 2000 is implicitly casted to the higher ranked
data type.
In SQL Server 7.0 real is higher than money so that every
multiplication or divison of a money and real value is real.
I think this is valid for SQL Server 2000 too.
My new project includes some very high money values and I
have a lot of multiplications (percentage up to 100) and
divisions (by rates of exchange).
So is it a good idea to cast explicitly every real value to
a money value in arithmetic operations like?
Klaus
www.trappdata.dehi,
you must be aware that when you do something with real datatype, in some
cases you may loose precision. even if it is a cent, it may matter to
someone.
peter
"Klaus Trapp" <Klaus.Trapp@.gmx.de> wrote in message
news:uKnj9hFSGHA.1780@.TK2MSFTNGP12.phx.gbl...
> Hallo,
> as far as I remember the result of an arithmetic operation
> in SQL Server 2000 is implicitly casted to the higher ranked
> data type.
> In SQL Server 7.0 real is higher than money so that every
> multiplication or divison of a money and real value is real.
> I think this is valid for SQL Server 2000 too.
> My new project includes some very high money values and I
> have a lot of multiplications (percentage up to 100) and
> divisions (by rates of exchange).
> So is it a good idea to cast explicitly every real value to
> a money value in arithmetic operations like?
>
> Klaus
> www.trappdata.de|||Klaus,
Money and real?. This is not a good combination because real is an
approximate number.
See is this can help.
monney vs numeric
http://groups.google.com/group/micr...r />
t=0&num=3
AMB
"Klaus Trapp" wrote:
> Hallo,
> as far as I remember the result of an arithmetic operation
> in SQL Server 2000 is implicitly casted to the higher ranked
> data type.
> In SQL Server 7.0 real is higher than money so that every
> multiplication or divison of a money and real value is real.
> I think this is valid for SQL Server 2000 too.
> My new project includes some very high money values and I
> have a lot of multiplications (percentage up to 100) and
> divisions (by rates of exchange).
> So is it a good idea to cast explicitly every real value to
> a money value in arithmetic operations like?
>
> Klaus
> www.trappdata.de
>
Showing posts with label real. Show all posts
Showing posts with label real. Show all posts
Monday, February 13, 2012
arithmetic operations with money and real
Labels:
arithmetic,
casted,
database,
hallo,
implicitly,
microsoft,
money,
mysql,
operationin,
operations,
oracle,
rankeddata,
real,
remember,
server,
sql,
type
Arithmetic error
When I run a view, I am getting an SQL (ODBC) error "Arithmetic overflow
error converting real to data type numeric." Below is the line of code in
the view that I think is causing the error (dbo.WorkerTimesheets.PayRate is
a real data type and has a value of 730). Can anyone help me fix it?
Thanks.
CONVERT(varchar(6), CONVERT(decimal(4, 2), dbo.WorkerTimesheets.PayRate)) +
'/' + dbo.PayRateCodes.RateName AS txtPayRate
DavidOf course it overflows. You reserve 4 places for the entire numeric, 2 of
which are decimal places.
730 already takes up 3 places. Add 2 for decimals to that and you get 5.
Give it more room. :) I'd suggest using decimal(12, 2). If this is used to
store wages or salaries, 8 places is more than enough. :)
Spend more time reading BOL.
ML|||Geez! When I said 8 I meant 10. Yes, it's late...|||Do not use CONVERT() when you have CAST(). Never use FLOAT or REAL
unless you know what you are doing. There are all kinds rounding
errors and they display with the 'E' format.
Why are you converting numerics to strings? The first rule of a tiered
architecture is that you never do formatting in the database.
Re-do your pay rates with DECIMAL() data type; you do not bill to 16
decimal places, do you? . Read up on floating point numbers.|||You are all correct. The "overflow" was my brain. When I look at it
now, it makes sense.
David
*** Sent via Developersdex http://www.examnotes.net ***
error converting real to data type numeric." Below is the line of code in
the view that I think is causing the error (dbo.WorkerTimesheets.PayRate is
a real data type and has a value of 730). Can anyone help me fix it?
Thanks.
CONVERT(varchar(6), CONVERT(decimal(4, 2), dbo.WorkerTimesheets.PayRate)) +
'/' + dbo.PayRateCodes.RateName AS txtPayRate
DavidOf course it overflows. You reserve 4 places for the entire numeric, 2 of
which are decimal places.
730 already takes up 3 places. Add 2 for decimals to that and you get 5.
Give it more room. :) I'd suggest using decimal(12, 2). If this is used to
store wages or salaries, 8 places is more than enough. :)
Spend more time reading BOL.
ML|||Geez! When I said 8 I meant 10. Yes, it's late...|||Do not use CONVERT() when you have CAST(). Never use FLOAT or REAL
unless you know what you are doing. There are all kinds rounding
errors and they display with the 'E' format.
Why are you converting numerics to strings? The first rule of a tiered
architecture is that you never do formatting in the database.
Re-do your pay rates with DECIMAL() data type; you do not bill to 16
decimal places, do you? . Read up on floating point numbers.|||You are all correct. The "overflow" was my brain. When I look at it
now, it makes sense.
David
*** Sent via Developersdex http://www.examnotes.net ***
Subscribe to:
Posts (Atom)