Azure storage - double decimal point ignored on save

Question

I have a value that is correctly stored in a property of an object, but when I save the changes to the Azure storage database, the double value is stored to the database ignoring the point (7.11000000003 is saved as 711). Also, the property is changed to 711.0.

How do I solve this problem?

The field is already set to double in the class and the database table.

Answer 1

Is your double value in its own field, or is it in the partitionkey or rowkey field? PartitionKey and RowKey are always strings.

I just created a simple test which writes and reads a row with a double field, and the values are preserved just fine. I modified the sample SmsMessage class from Bill Lodin's SMS code via msdev.com training (I took the int Delay field and changed it to a float, and renamed it to MyDouble for clarification):

public class SmsMessage: TableServiceEntity
{
    public double MyDouble { get; set; }
    public SmsMessage(string destination, string message, double myDouble)
    {
        PartitionKey = destination;
        RowKey = message;
        MyDouble = myDouble;
    }
    public SmsMessage()
        : base("", string.Format("{0:d10}", DateTime.Now.Ticks))
    {
    }
}

I then write to the SmsMessageTable:

smsTable.AddObject("SmsMessages", new SmsMessage(destination, message, myDouble));
smsTable.SaveChanges();

I view this in the table storage explorer, and my doubles are how I entered them (e.g. 1.2345).

I then retrieve with a simple linq query, for a given username in the partition key:

var results = from m in smsTable.SmsMessages
                      where m.PartitionKey.Equals(txtDestination.Text.Trim())
                      select m;

My double values are all preserved and strongly typed as doubles.

Answer 2

How are you checking the value? Local development storage uses SQL Express under the hood, so you might be opening up SQL and poking around there. I would avoid that and instead read back the value using the .NET storage client library. I suspect the value will come back correctly.

(Maybe in the local SQL-backed store, the value is stored in scientific notation?)

Answer 3

Although I appreciate the effort and probably I did not expose the case well enough, none of this really answer my question. This answer is just not to attribute the bounty unfairly. The bounty should not be attributed automatically to the best answer with >= 2 upvotes.

Answer 4

This problem seems to be due to the culture settings the Dev Storage is using. If you take a look at TableRow table inside the Dev Storage db, the data is stored as XML, and decimal values use the dot as decimal separator. Here in Brazil the dot is the thousands separator. I edited the data directly in the Dev Storage db, changing the dot to a comma (PT-BR decimal separator), and the value was read ok. That's odd, because if the value is read ok when we use the PT-BR decimal separator, it seems Dev Storage is using my current culture setting. But why the culture is not applied on saving the data?

PS: Changing the windows locale to EN-US solved the problem. I guess that's why this is the only post I could find about it.