[ОТВЕТИТЬ]
Опции темы
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, две ссылки выше, поглядим посмотрим
 
"Спасибо" -Den- от:
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, время: 18:29.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.