Same code, different systems and different data type intepretation

Question

I have a database which the schema was created and I imported data from excel (they exported it from their SQL Server database into excel format)

I am running SQL Server 2008R2 + updates They are running SQL Express 2008 R2

The problem is, on my system I am reading the values using .NET. A specific column of type decimal should actually be of double (unable to change it in production unfortunately)

For a specific data set, the value of this column is "0"

on my side, I read the data using GetDouble and that is fine - it gives me "0.0" (even though the actual value stored in the table is "0")

on their side, they get an error saying it cannot cast it to the right type. The value they get when they read is "0"

how can this be? I mean, same code completely, same database types, same data but reads it differently?

I am not sure how to go about fixing this or where to look on why the reading is different on both databases?

I would appreciate any help.

I am using stored procedures if it helps (although it shouldn't) to read the data and using the SqlDataReader class to read the incoming data.

here is the code I use to read the data from the SqlDataReader:

DedicatedResourceAssetCount = reader.IsDBNull(reader.GetOrdinal("dedicated resource asset count")) ? null : new Nullable<double>(reader.GetDouble(reader.GetOrdinal("dedicated resource asset count")))

And plenty more properties similar to the above. On my machine, the field stored in the DB is 0 and when the reader reads it, it is 0.0 On their machine, the field stored in the DB is 0 and when the reader reads it, it is 0 but of course, throws an InvalidCastException.

Answer 1

The work around, which I really do not like, seems to be the following:

object value = reader.GetValue(reader.GetOrdinal("column"));
double returnResult = Convert.ToDouble(value.ToString());

it seems to work but still odd on why it works fine in the original code on my systems.

Answer 2

A far shot is that floating point numbers are interpreted differently on the two systems. In many cultures the dot is used as a decimal separator but in other cultures the comma is used:

• 0.0
• 0,0

Is the second number a comma separated list of two integer zeroes or the floating point number 0.0? "My" and "their" system may use different cultures explaining the unexpected results you have.

However, the culture should only affect the interpretation of numbers if there is some form of conversion from text to number going on in your system. From your explanation it seems that you are querying a database and if the column type is a floating point the decimal separator should not matter.

Still, you could have a look at your system and the data in the system and look for problems with regard to the culture.

Going a bit more into the details of your question it seems that the error "their" system experiences is that reader.GetDouble throws an InvalidCastException. This means that the data stored in "their" database has another schema than "my" database and the column does not contain a double precision floating point number as expected. You have clearly stated that this is not the case but to find the source of the error you have to continue looking for unexpected differences between "my" and "their" system explaining the exception you get.