Хранилище Azure - двойная десятичная точка игнорируется при сохранении

Question

У меня есть значение, которое правильно хранится в свойстве объекта, но когда я сохраняю изменения в базе данных хранения Azure, двойное значение сохраняется в базе данных, игнорируя точку (7.11000000003 сохраняется как 711). Кроме того, свойство изменено на 711.0.

Как мне решить эту проблему?

Для поля и таблицы базы данных уже задано значение double.

Answer 1

Ваше двойное значение находится в своем собственном поле, или оно находится в поле sectionkey или rowkey? PartitionKey и RowKey всегда являются строками.

Я только что создал простой тест, который записывает и читает строку с двойным полем, и значения сохраняются очень хорошо. Я изменил пример класса SmsMessage из SMS-кода Билла Лодина через тренинг msdev.com (я взял поле int Delay, изменил его на float и переименовал в MyDouble для пояснения):

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))
    {
    }
}

Затем я пишу в таблицу SmsMessage:

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

Я просматриваю это в проводнике хранения таблиц, и мои двойники соответствуют тому, как я их ввел (например, 1.2345).

Затем я получаю простой запрос linq для заданного имени пользователя в ключе раздела:

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

Все мои двойные значения сохранены и строго напечатаны как double.

Answer 2

Эта проблема, по-видимому, связана с настройками культуры, которые использует Dev Storage. Если вы посмотрите на таблицу TableRow внутри базы данных Dev Storage, данные будут храниться в формате XML, а десятичные значения используют точку в качестве десятичного разделителя. Здесь, в Бразилии, точка - это разделитель тысяч. Я отредактировал данные непосредственно в базе данных Dev Storage, изменив точку на запятую (десятичный разделитель PT-BR), и значение было прочитано нормально. Это странно, потому что, если значение читается нормально, когда мы используем десятичный разделитель PT-BR, кажется, что Dev Storage использует мою текущую настройку культуры. Но почему культура не применяется для сохранения данных?

PS: изменение языкового стандарта Windows на EN-US решило проблему. Наверное, поэтому это единственный пост, который я смог найти об этом.

Answer 3

Как вы проверяете значение? Локальное хранилище разработки использует SQL Express под капотом, так что вы можете открыть SQL и ковыряться там. Я бы избегал этого и вместо этого считывал значение, используя клиентскую библиотеку хранилища .NET. Я подозреваю, что значение вернется правильно.

(Может быть, в местном хранилище, поддерживаемом SQL, значение хранится в научной нотации?)

Answer 4

Хотя я ценю это усилие и, возможно, я недостаточно хорошо раскрыл дело, ничего из этого не ответило на мой вопрос. Этот ответ просто не приписывает награду несправедливо. Награда не должна автоматически приписываться к лучшему ответу с> = 2 ответами.