current year to fraction( 5 )
Leonids....@dati.lv
еЭё РТПВМЕНЛБ ОБЫМБУШ :-((
IDS 7.31.TC2
пРБОШЛЙ. пУФБОПЧЙМБУШ УЙУФЕНБ ХЮёФБ ОБМПЗПЧ мБФЧЙКУЛПК тЕУРХВМЙЛЙ.
ч ФТЙДГБФЙ ЮЕФЩТёИ ПФДЕМЕОЙСИ зПУХДБТУФЧЕООПК уМХЦВЩ дПИПДПЧ
БРМЙЛБГЙС ЧЩМЕФБЕФ У ПЫЙВЛПК:
"-1263 A field in a datetime or interval is out of range or incorrect."
"оБЮБМПУШ - Y2K", - РПДХНБМ С.
оП ОЕФ. йУУМЕДПЧБОЙС ОБ НЕУФЕ РПЛБЪБМЙ, ЮФП ОЕ ТБВПФБЕФ subj, Ф. Е.
"SELECT CURRENT YEAR TO FRACTION( 5 ) FROM <any_table>"
ЧПЪЧТБЭБЕФ ХРПНСОХФХА ПЫЙВЛХ. б ФБЛЦЕ ОЕ ЮЙФБАФУС ФБВМЙГЩ,
ЙНЕАЭЙЕ ПРЙУБОЙС ФЙРБ:
CREATE TABLE my_table (
...
my_field DATETIME YEAR TO FRACTION(5)
DEFAULT CURRENT YEAR TO FRACTION(5),
...
);
пДОБЛП "UNLOAD INTO" ТБВПФБЕФ, ОП ЮФП ЬФБ ЛПНБОДБ ЧЩЗТХЦБЕФ?!
рПУМЕДОЙК УЙНЧПМ DATETIME РПМЕК - "(" - ПФЛТЩЧБАЭБСУС ЛТХЗМБС УЛПВЛБ!
1. лБЛ ФБЛПК УЙНЧПМ НПЗ ПЛБЪБФШУС Ч РПМЕ DATETIME?
2. лБЛ ФЕРЕТШ ТБУИМЕВБФШ ЪБЧБТЕООХА ОБ InformixЕ ЛБЫХ?
3. уЛПМШЛП ВХДХФ УФПЙФШ ЙУРТБЧМЕОЙС Й ЛФП ВХДЕФ РМБФЙФШ ОЕХУФПКЛХ ЪБ
РТПУФПК УЙУФЕНЩ?
оХ, Б ЧУЕН - ХДБЮЙ. рХУФШ Х ЧБУ ФБЛПЗП ОЕ УМХЮЙФУС.
мЕПОЙД.
Leonids....@dati.lv
Ещё проблемка нашлась :-((
IDS 7.31.TC2
Опаньки. Остановилась система учёта налогов Латвийской Республики.
В тридцати четырёх отделениях Государственной Службы Доходов
апликация вылетает с ошибкой:
"-1263 A field in a datetime or interval is out of range or incorrect."
"Началось - Y2K", - подумал я.
Но нет. Исследования на месте показали, что не работает subj, т. е.
"SELECT CURRENT YEAR TO FRACTION( 5 ) FROM <any_table>"
возвращает упомянутую ошибку. А также не читаются таблицы,
имеющие описания типа:
CREATE TABLE my_table (
...
my_field DATETIME YEAR TO FRACTION(5)
DEFAULT CURRENT YEAR TO FRACTION(5),
...
);
Однако "UNLOAD INTO" работает, но что эта команда выгружает?!
Последний символ DATETIME полей - "(" - открывающаяся круглая скобка!
1. Как такой символ мог оказаться в поле DATETIME?
2. Как теперь расхлебать заваренную на Informixе кашу?
3. Сколько будут стоить исправления и кто будет платить неустойку за
простой системы?
Ну, а всем - удачи. Пусть у вас такого не случится.
Леонид.
P.S. Чего-то с кодировкой не ладится.
Igor Zavgorodny
Leonids....@dati.lv wrote:
> Опаньки. Остановилась система учёта налогов Латвийской Республики.
> В тридцати четырёх отделениях Государственной Службы Доходов
Я почему-то был уверен, что ты связан с таможней (где то проскакивало
слово muita):-).
> апликация вылетает с ошибкой:
> "-1263 A field in a datetime or interval is out of range or incorrect."
Проверил на 7.22UC2 SCO UNIX и на 7.30TC3 NT. Не подтвердилось. Может
дело в настройках клиента? Я так понял, ты все проверял из SQL-Editor, а
как из dbaccess?
Чему у тебя равны DBDATE и DBTIME, у меня они установленны.
> 3. Сколько будут стоить исправления и кто будет платить неустойку за
> простой системы?
Однозначно, налогоплательщики.
>Ну, а всем - удачи. Пусть у вас такого не случится.
Спасибо на добром слове, мои разработчики четвертый год стараются
начинают тестирование новых информиксов с того, как ведет себя current.
--
Igor Zavgorodny
Head of SoftWare Department
KreditPromBank E-mail: dau...@kpb.ukrpack.net
Technology ProFIX E-mail: dau...@profix.kiev.ua
ICQ: 8237406
Igor Zavgorodny
Igor Zavgorodny wrote:
> Чему у тебя равны DBDATE и DBTIME, у меня они установленны.
Сорри, у меня они не установленны.
Petro Petin
<Leonids....@dati.lv> wrote in message
news:37E659BE...@dati.lv...
> Ещё раз здравствуйте :-)
> Ещё проблемка нашлась :-((
>
> "SELECT CURRENT YEAR TO FRACTION( 5 ) FROM <any_table>"
А с точностью до 5ти знаков -- это принципиально?
--
=============================================================
SY Petro Petin p...@antec.carrier.kiev.ua Software Developer
ANTEC (Advanced Network TEChnologies), Kiev, Ukraine
Phone:(380-44) 221-21-38 Fax: (380-44) 234-35-50
Shulzhenko Vasyl
Igor Zavgorodny <dau...@kpb.ukrpack.net> wrote in message
news:37E676CD...@kpb.ukrpack.net...
> Hi, Леонид.
>
> Leonids....@dati.lv wrote:
> > Опаньки. Остановилась система учёта налогов Латвийской Республики.
> > В тридцати четырёх отделениях Государственной Службы Доходов
> Я почему-то был уверен, что ты связан с таможней (где то проскакивало
> слово muita):-).
>
> > апликация вылетает с ошибкой:
> > "-1263 A field in a datetime or interval is out of range or incorrect."
> Проверил на 7.22UC2 SCO UNIX и на 7.30TC3 NT. Не подтвердилось. Может
Именно на IDS 7.31.TC2 подтвердилось. Причем только на Fraction(5).
Fraction(4) и менее работает.
Интересно, что при USEOSTIME=1 данный баг пропадает. Так что при
соответствующей проверке можно использовать как work around. (Если это так,
то неужели я спасу всю Государственную Службу Доходов Латвийской Республики
??
Вот гордиться то буду :)).
Правда ума не приложу, зачем в таком приложении такая точность - доли
милисекунд ??
Притом, что в WinNT получить доли секунды мне пока никак не удавалось (даже
с той самой USEOSTIME).
Вот уж проектировал кто-то умный, наверное с расчетом на 50 лет вперед и на
тысячи транзакций в секунду.
> >Ну, а всем - удачи. Пусть у вас такого не случится.
> Спасибо на добром слове, мои разработчики четвертый год стараются
> начинают тестирование новых информиксов с того, как ведет себя current.
Вот-вот. Прежде чем переводить production system на новую версию, надо бы на
ней несколько месяцев систему погонять. Кто-то тут уже говорил, что с ужасом
ждет перехода на новый релиз и это правильно :)
Зато будет человек во всеоружии встречать новые проблемы, на которые уже
кто-то наткнулся.
--
С уважением,
Василий Шульженко
Leonids....@dati.lv
> А с точностью до 5ти знаков -- это принципиально?
Клиентская часть разработана на "Centura Team Developer 1.1".
Этот инструмент допускает единственный формат DATETIME -
с точностью до пяти знаков.
Леонид.
Leonids....@dati.lv
> Я почему-то был уверен, что ты связан с таможней (где то проскакивало
> слово muita):-).
Таможня - одна из частей проекта.
> Проверил на 7.22UC2 SCO UNIX и на 7.30TC3 NT. Не подтвердилось.
Я ведь писал - IDS 7.31.TC2, на IDS 7.30.TC2 всё работало.
> Может
> дело в настройках клиента?
Настройки клиента никто не менял.
Проблема появилась после upgradа Informix сервера.
> Я так понял, ты все проверял из SQL-Editor, а
> как из dbaccess?
Аналогично. Нет разницы какого клиента использовать.
Centurу тоже можно. В DATETIME поле не может быть круглых скобок.
Ошибка возникает во время fetchа.
> Чему у тебя равны DBDATE и DBTIME, у меня они установленны.
Не установлены.
> Спасибо на добром слове, мои разработчики четвертый год стараются
> начинают тестирование новых информиксов с того, как ведет себя current.
Блин. Где ж ты раньше был? Теперь, похоже, нужно делать во-первых downgrade,
а во-вторых каким-то макаром исправлять данные. Пока, правда, не ясно как.
Леонид.
Leonids....@dati.lv
> Интересно, что при USEOSTIME=1 данный баг пропадает. Так что при
> соответствующей проверке можно использовать как work around. (Если это так,
> то неужели я спасу всю Государственную Службу Доходов Латвийской Республики
> ??
Государственную Службу Доходов Латвийской Республики я уже спас.
Именно установив в onconfige USEOSTIME в 1. По-моему это первая
версия Informixа для NT, где этот параметр влияет на поведение сервера.
Да ещё так сильно.
> Вот гордиться то буду :)).
Я уже горжусь.
> Вот-вот. Прежде чем переводить production system на новую версию, надо бы на
> ней несколько месяцев систему погонять.
Вот-вот. Да ещё в условиях близким к боевым.
Но это, как известно, требует времени и денег.
А обычно не хватает ни того, ни другого.
А перейти мы хотим уже давно из-за:
1. colmin, colmax (кривые значения и, как следсвие - плохие планы и долгое
выполнение запросов);
2. GLS (поиск LIKE 'VORONCOV%' по nchar/nvarchar полю раз в 200 медленнее, чем
по char/varchar);
3. SQLBreak(), SQLCancel() (нет возможности прервать долго выполняющийся
запрос);
4. ISM (останавливается гад, причём абсолютно непредсказуемо);
5. OPTCOMPIND (после 7.30.TC2 до 7.31.TC2 не работал);
6. SDK (прекомпилятор создаёт некомпилируемый код, при чтении BLOBов забывает
освобождать память);
7. NVL() (при определённых условиях создаёт memory leak вплоть до полной
неповоротливости сервера).
Поэтому мы были так рады, что хоть некоторые пункты в этой версии исправлены,
что
поторопились с upgradом. Хорошо ещё, что так закончилось.
> Кто-то тут уже говорил, что с ужасом
> ждет перехода на новый релиз и это правильно :)
А по-хорошему-то должно быть наоборот - с радостью. IMHO.
> С уважением,
> Василий Шульженко
Спасибо за потраченое на мою проблему время.
Леонид.
Shulzhenko Vasyl
<Leonids....@dati.lv> wrote in message
news:37E895E2...@dati.lv...
> Shulzhenko Vasyl wrote:
>
> > Интересно, что при USEOSTIME=1 данный баг пропадает. Так что при
> > соответствующей проверке можно использовать как work around. (Если это
так,
> > то неужели я спасу всю Государственную Службу Доходов Латвийской
Республики
> > ??
>
> Государственную Службу Доходов Латвийской Республики я уже спас.
> Именно установив в onconfige USEOSTIME в 1. По-моему это первая
> версия Informixа для NT, где этот параметр влияет на поведение сервера.
> Да ещё так сильно.
> > Вот гордиться то буду :)).
> Я уже горжусь.
Тогда я тоже буду гордиться :)
> > Вот-вот. Прежде чем переводить production system на новую версию, надо
бы на
> > ней несколько месяцев систему погонять.
>
> Вот-вот. Да ещё в условиях близким к боевым.
> Но это, как известно, требует времени и денег.
> А обычно не хватает ни того, ни другого.
>
> А перейти мы хотим уже давно из-за:
> 1. colmin, colmax (кривые значения и, как следсвие - плохие планы и долгое
> выполнение запросов);
> 2. GLS (поиск LIKE 'VORONCOV%' по nchar/nvarchar полю раз в 200 медленнее,
чем
> по char/varchar);
А что, в этой версии GLS работает по другому ?
А цифра 200 меня, признаться, озадачила. Неужели именно в 200 ?
И это при использовании индексов в обоих случаях ? А если без индексов ?
И на каких обьемах ? Насколько вообще можно серьезно относится к такой цифре
?
Уж больно впечатляет... Я и до этого знал, что лучше избегать nchar/nvarchar
и всегда это советовал, но предполагал разницу в быстродействии (кроме
дополнительных проблем) от 50 до 100%. А тут такое....
Leonids....@dati.lv
> > 2. GLS (поиск LIKE 'VORONCOV%' по nchar/nvarchar полю раз в 200 медленнее,
> чем
> > по char/varchar);
>
> А что, в этой версии GLS работает по другому ?
Нет, также. К сожалению.
> А цифра 200 меня, признаться, озадачила. Неужели именно в 200 ?
Зависит от количества данных. Если в таблице 10 записей,
то разница незаметна. А вот если 3 млн, то:
char/varchar - результат начинает приходить сразу; трудно замерить
время реакции, но меньше секунды - это точно; остальные записи
подтягиваются где-то ещё секунду;
nchar/nvarchar - первая запись приходит через 2 минуты (120 / 0.5 = сколько?);
остальные подтягиваются ещё где-то секунд 40;
Всё это - с использованием индекса, по крайней мере так написано в explainе.
> И это при использовании индексов в обоих случаях ? А если без индексов ?
> И на каких обьемах ?
Вот и проверь, если время есть. Можно, конечно, заниматься точными замерами, но,
как сам понимаешь, есть другие дела. Одно ясно - GLS глючит.
Как говорил Шеворошкин: "Не "не работает", а "работает значительно медленнее"".
> Насколько вообще можно серьезно относится к такой цифре
> ?
> Уж больно впечатляет... Я и до этого знал, что лучше избегать nchar/nvarchar
> и всегда это советовал, но предполагал разницу в быстродействии (кроме
> дополнительных проблем) от 50 до 100%. А тут такое....
>
Леонид.