Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли > Супермаг Плюс (Супермаг 2000)

Ошибка приема карточки складского учета и TimeZone : Супермаг Плюс (Супермаг 2000)

29.03.2024 11:18


15.10.2014 14:42
-Den-
 
В преддверии предстоящих событий
Windows KB2998527, часовой пояс RTZ
Патчи в связи с изменением часовых поясов в 2014

Может появиться такая проблемка (СМ 1.029.3), при рассылке карточки или ее изменений получим сие
Цитата:
----- Ошибка приема -----
Пакет: 141015123427_740569_22.XML
Тип объекта: Карточка складского учета
Идентификатор объекта: 003403
-- Уровень вложения 0 --
Сообщение: Невозможно обновить в БД объект «CD, 003403», таблица «SMCARDTAX»
Исключение: System.Exception
Источник:
Метод:
-- Уровень вложения 1 --
Сообщение: ORA-02290: check constraint (SUPERMAG.SMCCARDTAXDATEFROM) violated

Исключение: System.Exception
Источник:
Метод:
Вроде как Супермагу все равно на таймзоны, но вот если в ЦО и МХ время/дата одинаковые, а часовые пояса разные (где то стоит "прошлое обновление времени", а где то нет) то, ловите эту ошибку. Если "выравнять" пояса, к примеру +4москва в ЦО(предыдущее обновление есть) и +4Баку(обновления нет) то почтовик ошибку не даст и все пройдут норм.

Параметры времени "хорошо показывает" команда wmic timezone get * /value, обратите внимание на первые три строчки, в первом и третьем "зашиты наличие или отсутствие галочки лето/зима", что тоже может вызывать казусы при обмене, при том что на данный момент этого параметра нету в интерфейсе со стоящим "прошлым обновлением времени"

Описанное выше касается нынешнего времени, что произойдет апосля 26.10.2014, две ссылки выше, поглядим посмотрим
15.10.2014 15:00
OlegON
 
А это на каком Oracle?
Смотрим в книгу - видим фигу DDL:
Цитата:
ALTER TABLE "SUPERMAG"."SMCARDTAX" ADD CONSTRAINT "SMCCARDTAXDATEFROM" CHECK (DateFrom>=TO_DATE('19700101','YYYYMMDD')) ENABLE
и что-то у меня понимания, каким образом тут может вылезти эта ошибка, нет... Зато закрадываются подозрения, что где-то могут заполняться даты кривыми данными... Хотелось бы раскопать...
15.10.2014 15:15
-Den-
 
Oracle 10.2.0.4

01.01.1970 для всех одна, кто бы ее трогал, предположение на момент возникновения этой ошибки было такое - что дата была "01011970 - 1 час", сместили пояс, загрузка прошла, дальше копать не стал.
15.10.2014 15:23
OlegON
 
1970 вообще не при чем. Какая-то засада приезжает в DateFrom. И у меня нет понимания, почему ею не подавился код до того, как этот мусор поехал в базу. Соответственно, не исключено, что мусор и продолжает приезжать, просто уже попадает в нужные рамки. В коде где-то ошибка.
15.10.2014 15:42
-Den-
 
Тут забыл уточнить момент, не знаю имеет это значение, обмен в почтовике идет через XML фильтр (версии ЦО_1.029 / МХ_1.029.3), открыл пакет и вот что в нем есть
Цитата:
-<SMCARDTAX>
<ARTICLE>008138</ARTICLE>
<RGNID>-1</RGNID>
<DATEFROM>1970-01-01T00:00:00+04:00</DATEFROM>
<DATETO>9999-01-01T00:00:00+04:00</DATETO>
<TAXGROUPID>1</TAXGROUPID> </SMCARDTAX>
Может почтовик при конвертации XML в свой пакет строку 1970-01-01T00:00:00+04:00 преобразует со сдвигом -1
15.10.2014 15:45
OlegON
 
Скорее всего... Ну, вот и бага из детских...
15.10.2014 15:47
-Den-
 
Во те на, не в курсе, можно просветить где раки зимуют и по чем опиум для народа))
16.10.2014 16:02
vdm
 
Цитата:
OlegON А это на каком Oracle?
Есть подозрение, что на любом. Если таймзоны на серверах Супермага разные, может вылезти расхождение в обработке времени при почтовом обмене. На 9i такое встречал, если не в smcardtax, то в другом месте.

C другой стороны, может влиять параметр в адм. модуле Почта - Смещение локального зимнего времени.
Часовой пояс GMT +3, время: 11:18.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.