an easy answer, but here goes:
I have a column entitled Sequ which is defined as a Decimal with
Precision 10 and Scale 5. In an ASP.NET page, I'm performing a
calculation which is inserted into the Sequ column. I'm doing a
response.write, which enables me to see that the numbers are in fact
being calculated correctly complete with a string of numbers after the
decimal, but when I pull the numbers out to use on the page or access
the table, Sequ lists all numbers as integers. I'm using a stored
procedure in which I'm declaring the @.calc parameter (the calculated
value which is being inserted) as a Decimal -- I don't know what I'm
doing wrong. Help appreciated...thanks.
ErikOn 2 Jan 2005 12:27:13 -0800, erikthenomad@.hotmail.com wrote:
(snip)
> I'm using a stored
>procedure in which I'm declaring the @.calc parameter (the calculated
>value which is being inserted) as a Decimal
Hi Erik,
Like this
DECLARE @.calc decimal (10,5)
or like this
DECLARE @.calc decimal
In the latter case, you've declared the variable with default scale (18)
and default precision (0).
In the former case, there must be something else wrong. It might help if
you post the complete code for the stored procedure.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Hugo,
Thanks for the help -- I ended up trying "smallmoney" while awaiting a
response, which did the trick quite nicely (I don't need more than four
decimal places); are there any drawbacks to that? I think the issue
was that I had not specifically declared the precision of the decimal,
thinking it would be taken care of already since I had already declared
it in the table design.
Erik|||On 2 Jan 2005 13:47:52 -0800, erikthenomad@.hotmail.com wrote:
>Hugo,
>Thanks for the help -- I ended up trying "smallmoney" while awaiting a
>response, which did the trick quite nicely (I don't need more than four
>decimal places); are there any drawbacks to that?
Hi Erik,
The value will be implicitly ocnverted from decimal (10,5) to smallmoney.
You'll lose the fifth decimal, as smallmoney and money have a precision of
four decimal places. The maximum for smallmoney is over 200,000, so you
won't have problems with that. The conversion will have a very small
effect on performance. If the parameter is used in a WHERE clause and
compared to a decimal column, the parameter will be converted back.
The main drawback is that you'll fail to understand the logic when you
have to get back to the code, several months from now.
> I think the issue
>was that I had not specifically declared the precision of the decimal,
>thinking it would be taken care of already since I had already declared
>it in the table design.
If you declare a variable, SQL Server can't know if you'll use it to store
values from a column, let alone know for which column. So SQL Server will
just use the defaults if you don't specify precision.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)sql
