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

-Den- · █ 15.10.2014 14:42

В преддверии предстоящих событий
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, две ссылки выше, поглядим посмотрим

OlegON · █ 15.10.2014 15:00

А это на каком Oracle?
Смотрим в книгу - видим фигу DDL:

Цитата:

ALTER TABLE "SUPERMAG"."SMCARDTAX" ADD CONSTRAINT "SMCCARDTAXDATEFROM" CHECK (DateFrom>=TO_DATE('19700101','YYYYMMDD')) ENABLE

и что-то у меня понимания, каким образом тут может вылезти эта ошибка, нет... Зато закрадываются подозрения, что где-то могут заполняться даты кривыми данными... Хотелось бы раскопать...

-Den- · █ 15.10.2014 15:15

Oracle 10.2.0.4

01.01.1970 для всех одна, кто бы ее трогал, предположение на момент возникновения этой ошибки было такое - что дата была "01011970 - 1 час", сместили пояс, загрузка прошла, дальше копать не стал.

OlegON · █ 15.10.2014 15:23

1970 вообще не при чем. Какая-то засада приезжает в DateFrom. И у меня нет понимания, почему ею не подавился код до того, как этот мусор поехал в базу. Соответственно, не исключено, что мусор и продолжает приезжать, просто уже попадает в нужные рамки. В коде где-то ошибка.

-Den- · █ 15.10.2014 15:42

Тут забыл уточнить момент, не знаю имеет это значение, обмен в почтовике идет через 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

OlegON · █ 15.10.2014 15:45

Скорее всего... Ну, вот и бага из детских...

-Den- · █ 15.10.2014 15:47

Во те на, не в курсе, можно просветить где раки зимуют и по чем опиум для народа))

vdm · █ 16.10.2014 16:02

Цитата:

OlegON ➤ А это на каком Oracle?

Есть подозрение, что на любом. Если таймзоны на серверах Супермага разные, может вылезти расхождение в обработке времени при почтовом обмене. На 9i такое встречал, если не в smcardtax, то в другом месте.

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