Access и региональные настройки

← →
ALS © (2007-04-13 12:53) [0]

Уважаемые мастера, столкнулся с непонятной проблемой.
Есть база Access 2003 c двумя таблицами, одна из них содержит несколька полей "числовое (Двойное с плавающей точкой)", другая - поле "Дата/время".
Подключаюсь к базе с помощью TADOConnection, строка "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + путь + ";Persist Security Info=False";
Данные заношу через TADOQuery (INSERT INTO ... VALUES...), типы параметров для указанных полей ftFloat, ftDateTime.
Если региональные настройки американские, все работает.
При русских настройках правильно срабатывает только для одной (первой) записи, для остальных записей на плавающие поля ругается "Data type mismatch in criteria expression", для поля даты меняет местами день и месяц, если может (день <= 12).
Можно ли как-нибудь побороть эту проблему? С точкой вместо запятой можно жить, но если ставить формат даты MM/DD/YYYY, то заказчик этого не поймет

← →
sniknik © (2007-04-13 13:14) [1]

> Можно ли как-нибудь побороть эту проблему?
использовать параметры...

и да, чуть не забыл, вместо TADOQuery TADOCommand.

← →
ALS © (2007-04-13 13:50) [2]

Параметры и использовал.
TADOCommand - спасибо, попробую

← →
sniknik © (2007-04-13 14:06) [3]

> Параметры и использовал.
и какой тогда формат для ftDateTime? ты уж определись, либо строка в формате "MM/DD/YYYY"(/другом, неважно каком) либо дата - число без всяких форматов.

p.s. ошибка в 17й строке.

← →
ALS © (2007-04-13 15:05) [4]

> ошибка в 17й строке.

Функция записи данных:
Query_insMR: TADOQuery; function SaveMainResult(const Op, CName, St, Waf, PC: string; Chip: integer; Res: boolean): boolean; begin with Query_insMR do try Parameters.Items[0].Value := Op; Parameters.Items[1].Value := CName; Parameters.Items[2].Value := St; Parameters.Items[3].Value := Waf; Parameters.Items[4].Value := PC; Parameters.Items[5].Value := Chip; Parameters.Items[6].Value := Ord(Res); Parameters.Items[7].Value := Now; Result := ExecSQL > 0 except on E: exception do begin Application.MessageBox(PChar(E.Message), "Error", MB_ICONHAND+MB_TASKMODAL); Result := False end end; end;
Содержимое Query_insMR.SQL:
INSERT INTO MainResult ( Operator,ChipName,NSet,Wafer,PassCard,ChipNumber,ChipResult,CurDate) VALUES (:POp,:PCNm,:PSt,:PWf,:PCrd,:PNum,:PRes,:PD)
Типы параметров:
PD - ftDateTime
строка в формате "MM/DD/YYYY" - это американский формат даты. Винда так отображает.

← →
sniknik © (2007-04-13 17:12) [5]

> Типы параметров:
> PD - ftDateTime
ну если тип параметра действительно предопределен как ftDateTime, и заносится действительно Parameters.Items[7].Value := Now; то это не та 17я строка...
вернее поле даты(этот параметр) тут не причем... ошибка от другого поля.

> строка в формате "MM/DD/YYYY" - это американский формат даты. Винда так отображает.
отображает и Гейтс с ней, при чем тут параметр/запрос, он в отображении никак не участвует. не путай мерседес и его вид в бинокле...

← →
ALS © (2007-04-13 18:38) [6]

Попробовал TADOCommand - работает чуть быстрее, чем TADOQuery, но эффект искажения даты для русских региональных настроек остался.

> не путай мерседес и его вид в бинокле...

Не по адресу. В [0] писал, что с американскими настройками все работает, но заказчику не нравится

← →
Jan1 (2007-04-13 18:47) [7]

> но эффект искажения даты для русских региональных настроек
> остался.

тебе ж объяснили, что как хранятся данные и как отображается - вещи не взаимосвязанные.
Оставь только CurDate в запросе и попробуй выполнить несколько раз свой запрос. Ошибка будет?

← →
ALS © (2007-04-13 19:15) [8]

> Оставь только CurDate в запросе

Поведение программы не изменилось. Первая запись корректна, для всех последующих меняет местами день и месяц (специально установил текущую дату 12.04.2007)

← →
sniknik © (2007-04-13 20:22) [9]

> Первая запись корректна, для всех последующих меняет местами день и месяц
это характерная особенность аксеса при конвертировании в дату со строки(!!!) откуда бы там она у тебя не была.
почему так происходит могу обьяснить но это не поможет с твоими "тараканами"... (так думаю ;)

вот для примера запрос (в Table1 должна быть минимум 1 запись)
SELECT TOP 1 CDate("31/12/2006") FROM Table1
UNION ALL
SELECT TOP 1 CDate("12/31/2006") FROM Table1

что получится? получится 2 одинаковые даты, т.к. аксес при конвертировании (именно при конвертировании прошу заметить) действует по принципу, пытаемся по локальным настройкам получилось? нет? пробуем по другому. список вариантов довольно впечатляющ (я тут както вариантов 10-16 приводил, разных)
кроме того у него есть такая вещь как авто конвертирование, т.е. не обязательно явно CDate писать в некоторых случаях, когда действие очевидно. инсерт это именно такой случай, при записи в поле даты будет попытка преобразования в нее с с любого исходного.
...
блин, пока писал, меня осенило, у тебя похоже само поле в таблице не дата а строка(!!!), тото ты так настойчив со своим форматом... и при внесении в строку с даты тоже автоприведение сработает...
ндаааа... а мы тут головы ломаем... срочно в магазин за метлой! стране дворников не хватает!

← →
ALS © (2007-04-14 10:53) [10]

Для любителей давать советы про метлу и немогущих въехать в написанное в [0] и [4] попробую разжевать:
В таблице поле "Дата/время", тип параметра запроса - ftDateTime, записываю значение, возвращаемое функцией Now (double).
Где ты увидел строку?
Как заставить аксес при конвертировании всегда использовать именно локальные региональные настройки?

Вопрос снят. Если даты в параметр типа ftString заносить строку, то access ничего не путает.
Аналогично для чисел.

> Где ты увидел строку?
по поведению аксеса, гдето есть, т.к. такое только при преобразованиях со строк.

> Как заставить аксес при конвертировании всегда использовать именно локальные региональные настройки?
так тебе и ответили, параметры с типом даты и полем даты не требуют преобразований (и никакой формат не нужен!!!) поэтому локальные настройки побоку, работает всегда одинаково, при любых.
ты этого до сих пор не понял, судя по всему раз настаиваеш.

> Если даты в параметр типа ftString заносить строку
т.е. до этого когда ты уверял что у тебя параметр типа ftDateTime ([4]), ты попросту врал?

> то access ничего не путает
только если вносить в правильном формате, том с которого он первым преобразовывает. см. пример в [9], можеш сменить условия и эти 2 строки через строковой параметр инсертом вставить, явное преобразование уже будет не нужно, но даты в значениях поля будут все одно одинаковы.
а так, если сам не запутаешься то и он ничего не спутает.

> Где ты увидел строку?
+ [1] > формат даты MM/DD/YYYY
формат у даты, может быть только в представлении ее строкой. (т.е. хотя ты и не говоришь этого явно, но везде подразумеваешь это)

> параметры с типом даты и полем даты не требуют преобразований

Может оно и так, но имхо эти преобразования таки происходят где-то между выдачей запроса на запись и собственно записью, иначе не могу себе объяснить поведение access"а.

Пока нашел только один путь решения проблемы:
заменил тип параметра ftDateTime на ftString и, соответственно,
Parameters.Items[7].Value := Now; на Parameters.Items[7].Value := DateTimeToStr(Now);
При этом подпольное преобразование, выполняемое access"ом, заменилось на явное преобразование, выполняемое delphi в соответствии с региональными настройками, и все работает OK.
Скорость занесения записей, кста, при этом не снизилась.

> формат даты MM/DD/YYYY

Так это в региональных настройках

> ALS (14.04.2007 10:53:10) [10]

А где ты увидел тут форматы, тут исключительно двоичные числа

Access и региональные настройки Найти похожие ветки