| Summary: | Ошибка could not find member 1(2077329,2077329) of opfamily 2078717 | ||
|---|---|---|---|
| Product: | SELTA@Etersoft | Reporter: | Станислав Коробейников <stas> |
| Component: | SQL-сервер | Assignee: | Калюхович Юрий <goga> |
| Status: | CLOSED FIXED | QA Contact: | Станислав Коробейников <stas> |
| Severity: | minor | ||
| Priority: | P4 | CC: | goga, stas |
| Version: | 1.1.0 | ||
| Target Milestone: | версия 1.0.4 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | ||
| Дата напоминания: | |||
| Bug Depends on: | |||
| Bug Blocks: | 6158 | ||
повторил ошибку.
запрос:
SELECT "dh"."iddoc", "dh"."sp14074"
FROM "dh14087" "dh", "tmpdelrec" "delrec"
WHERE "delrec"."type" = SUBSTR (CAST(("dh"."sp14074") as mvarchar), 1, 2) AND "delrec"."mdid" = SUBSTR (CAST(("dh"."sp14074") as mvarchar), 3, 4) AND "delrec"."objid" = SUBSTR (CAST(("dh"."sp14074") as mvarchar), 7, 9);
временная таблица tmpdelrec имеет поля с типами mchar(2), mchar(4) и mchar(9)
ошибка происходит в сравнении mchar c mvarchar именно в предложении WHERE. Наш тест был в SELECT'е и работал
> ошибка происходит в сравнении mchar c mvarchar именно в предложении WHERE. Наш
> тест был в SELECT'е и работал
уточнение:
сравнивается mchar(2) и substr(cast(pole1 as mvarchar),1,2)
причем изначально pole1 было типа mchar(23), затем приводится к mvarchar, передается в функцию substr, и в сравненении выдается ошибка
источник ошибки - сравнение.
когда-то решалось с помощью функций mv_mc_icase_eq(b mvarchar, a mchar ) и mc_mv_icase_eq(b mchar, a mvarchar ) - бага #3601 потом от них отказались, т.к. заработало и без них. сейчас снова всплыло. добавление их решает проблему, 1С не падает, выдает, что удалить объект невозможно на постгри-9.0 (на altlinux 6 beta 32bit, virtualbox) в инициализированной сельтой базе ошибки нет изначально; ошибка только на pgsql(8.4.4) исправляю тест, на будущее. Надо в установочных скриптах и скриптах обновления сделать создание этих функций. При этом надо сделать тест с проверкой. Т.е. функция проверяет, и если ловит исключение создает наши фукции, если нет возвращает назад родные mchar-овские. (В ответ на comment #4) > Надо в установочных скриптах и скриптах обновления сделать создание этих > функций. При этом надо сделать тест с проверкой. > Т.е. функция проверяет, и если ловит исключение создает наши фукции, если нет > возвращает назад родные mchar-овские. это сделал. не смог на свежесозданных базах воспроизвести ошибку. в новых базах функции берутся из $libdir/mchar, в дампе нашей базы оттуда же. скорее, используются разные версии патчей с mchar-ом... загрузил дамп, где воспроизводится ошибка. функции вытягиваются из mchar (патча). Интересно, что прямой вызов функции ( mv_mc_icase_eq() ) выполняется без ошибок, а на тестовых таблицах все падает. после долгих исследований выяснилось, что стандартные функции из патча mchar не работают из-за модификатора IMMUTABLE. Если заменить его на VOLATILE - то все заработает. Коммитим изменения в сельту 1.1.0 и наверное, можно даже написать Бартунову? закоммитил, пересобрал и выложил 8 revision сельты. багу закрываю. Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять. |
ERROR: could not find member 1(2077329,2077329) of opfamily 2078717 STATEMENT: SELECT "dh"."iddoc", "dh"."sp14074", "journ"."ismark" FROM "dh14087" "dh", "_1sjourn" "journ", "tmpdelrec" "delrec" WHERE "delrec"."type" = SUBSTR (CAST(("dh"."sp14074") as mvarchar), 1, 2) AND "delrec"."mdid" = SUBSTR (CAST(("dh"."sp14074") as mvarchar), 3, 4) AND "delrec"."objid" = SUBSTR (CAST(("dh"."sp14074") as mvarchar), 7, 9) AND "dh"."iddoc" = "journ"."iddoc" Бутылка: selta/our1c77 Заходим монопольно. Пользователь Стас. Операции -> Удаление помеченный объектов Снимаем выделения. Выбираем: Справочник: Сотрудники Уволенные/Митрофанов... . Нажимаем Контроль. Я видел, как запрос упал c ошибкой в 1с: SQL State: HY000 Native: 1 Message: No query has been executed with this handle Но видел и как повис, при этом в логах postgres все равно была ошибка.