2009-07-24 1 views
1

Это два раза. У меня есть база данных Access и таблица, содержащая поля MS Access Currency. Мои клиенты в США используют десятичные значения, например 1,23, а мои клиенты в Эквадоре используют десятичные значения, например 1,23.Что такое язык: OleDb.Currency или OleDb.Decimal?

У меня есть код устаревшего кода ADO, и я попытался создать параметры ADODB с типом adDecimal, а также с типом adCurrency. В любом случае после выполнения моей команды ADODB данные в Access поступают как 1,23 (ожидается) для США и 123,00 для Эквадора (не ожидается).

В моем .NET-коде я попытался использовать параметры OleDb с типом OleDb.Currency и OleDb.Decimal. Кажется, что OleDb.Currency - это знание локали, но OleDb.Decimal - нет.

Голова крутится. Кто-нибудь знает правильное использование ADO для международной валюты для моего устаревшего кода, а также правильный способ записи параметров .NET по мере продвижения нашей кодовой базы?

Спасибо!

ответ

0

Хорошо, поэтому после некоторого дополнительного копания кажется, что типы «Валюта» предпочтительнее типов «Десятичный». Другими словами, использование adCurrency для ADO или OleDb.Currency будет работать для сохранения десятичных значений в поля MS Access Currency.

Только в случае, если это подходит для кого-то еще - я найти очень странное поведение в случае ADO следующим образом:

Мой код инстанс новый ADODB Command и создать коллекцию параметров - в том числе некоторые набраны, как adCurrency. Затем я начал обновлять несколько записей в моей базе данных. Я повторно использовал один и тот же командный объект для каждого обновления и вызвал метод для сброса всех полей параметров до 0 до того, как был запущен следующий блок обновлений. Это привело к плохим данным в моих полях (см. Начальную проблему, описанную выше). Я пробовал много вещей, чтобы исправить это и не увенчался успехом. Я даже прокомментировал вызов метода ResetParameters, чтобы убедиться, что поведение не было связано.

Исправление: вместо повторного использования командного объекта я, наконец, решил создать новый новый объект команды перед каждым блоком обновления. Внезапно все мои десятичные значения появились в Access правильно, независимо от моих настроек локали.

Таким образом, после вызова метода Execute что-то было изменено на моем объекте команды, так что параметр adCurrency при последующих обновлениях был нарушен. Кстати, результаты были следующими: значение 4,32 появится в Access как 432 (это будет форматирование валюты Эквадора). Мой код не был слишком сложным, и я не буду публиковать его здесь, но мы были вдвоем, глядя на это довольно сложно, и мы просто не видели ничего, что могло бы это объяснить. На самом деле идея создания нового экземпляра возникла, когда мы написали тестовое приложение, которое вызвало только одно обновление, и ТОЧНЫЙ ИСТОЧНИК КОДА, РАБОТАЕМ В ТЕСТЕ, ОЖИДАЕМОМ.

Остерегайтесь повторного использования объектов команды ADO для нескольких обновлений, если вы пишете локализованное приложение.

0

Внутренние типы не знают о локали, они просто цифры.
Язык влияет на то, когда вы захватываете их со входа и отображаете их в окне или отчете.

0

@Eduardo, Я понимаю, что вы говорите об форматировании. В этом случае я вообще не выводю данные на пользовательский интерфейс или какой-либо вывод. Я получаю неожиданное поведение, когда полностью выдаю обновление базы данных из кода.

Я действительно не знаком с тем, что происходит на низком уровне с провайдером, таким как Jet (используется для базы данных Access). Переводит ли параметр команды в фактическую строку SQL, которая анализируется позже, или параметры, потребляемые напрямую? Я не уверен.

Я уверен, что поведение, которое я вижу, указывает на то, что авторы логики поставщика различают типы «валюты» и «десятичный» таким образом, что числовые параметры помещаются в соответствующий MS Access тип. Когда мы используем неправильный тип параметра, преобразование происходит внутри и испортит результат.

По-видимому, более распространенная проблема (и более легкая для поиска исправлений) связана с датами. В качестве примера, используя Эквадор, формат даты в этом регионе день/месяц/год вместо месяца/дня/года в США. Это SQL строка, как это не будет хорошо работать: (! Идти США)

SET UPDATE Клиент DateOfBirth = # 03/06/1970 #

SQL-анализатор всегда будет читать эту дату как 6 марта но в Ecudaor это на самом деле означает 3 июня. Чтобы исправить это, чтобы всегда преобразовать даты в общепринятый формат перед добавлением их в строку SQL:

UPDATE SET Клиент DateOfBirth = # 1970-06-03 # (3 июня 1970)

' gotcha 'вокруг валюты был немного более тонким - и тот факт, что мой ADO-параметр не вел себя во время итерации цикла (см. принятый ответ выше), был странным.

0

Используйте Double вместо Decimal, чтобы объявить тип столбцов в базе данных MSAccess. Работает и не зависит от региональных настроек.

 Смежные вопросы

  • Нет связанных вопросов^_^