DataSet Limitation?

[Guest]

I have a SQL table that has a column defined as Sql Data Type decimal(38,15). In case you are wondering, the precision and scope are that large because it contains 'scientific' numbers which require a range of that size

Anyway, if I try to fill a DataSet with a DataAdapter, with a simple "select * from table", I get

System.OverflowException: Conversion overflow

when it gets to a row that has a column over some value (and I'm sure under some value as well)

For instance: "1000000000000000.000000000000000" produces the erro

Does anyone know what this value is? And is there anyway around this, or is it simply the case that .NET DataSet can't handle a Sql Data Type decimal with a precision and/or scope of that size

TI

 

[Guest]

On further review, it looks like the Fill method of the DataAdapter uses int32, which would explain it.

Is there any way around this, that anyone can think of?

jdn

 

[Kevin Yu [MSFT]]

Hi,

This is an know issue, that a "Convertion Overflow" exception will be
thrown if the precision of the decimal field is greater than 28. This will
be fixed in the next version of VS.net. The workaround is to use methods
like SqlDataRead.GetSqlDecimal() to get the decimal values.

If anything is unclear, please feel free to reply to the post.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Guest]

I am still having problems with it.

If I try to pull over the value "1000000000000000.000000000000000", I get an overflow. I've tried casting it into decimal and long (I would think long should work), but same "Conversion overflow error." And you can't cast SqlDbDecimal into a double.

What should I do?

jdn

 

[Guest]

Okay, I got it. You have to do:

"DataReader.GetSqlDecimal[0].ToDouble()"

and then you are good to go. I never understand why the syntax of languages are such that "(double)DataReader.GetSqlDecimal[0]" doesn't work, but there is a method to do it.

I guess there is a method to the madness.

jdn

 

[EBites]

If you don't mind losing some of the decimal accuracy, casting the value returned by the SQL statement as a float also seems to solve the problem.