Платформа: Windows XP, 1C 7.7 (27 релиз) компонента опер. учет, SELTA@ETERSOFT 1.03 Конфигурация на базе типовой: Торговля+склад Проблема 1 (Критическая): 1. Открываем любой журнал (например складские документы) 2. Выбираем непроведенный документ (причем тот, который заведомо не проведется) 3. Пытаемся провести 4. 1С выдает сообщение о том, что документ не проводится (при этом список документов в форме журнала очищается) 5. Журнал оставляем как есть (пустой список) 6. создаем любой документ (например, чек ККМ), записываем его 7. Заходим в журнал документов (в нашем случае журнал чеков) и пытаемся: а. Изменить время документа (ошибка duplicate key constraint "parent__1scrdoc") б. Провести (ошибка duplicate key constraint "parent__1scrdoc") 8. С ошибкой помогает справится пересчет служебных данных Проблема 2 (Неприятная): 1. Выбираем непроведенный документ (причем тот, который заведомо не проведется) 2. 1С выводит сообщение об ошибке (игнорируем его) + опять получаем пустой журнал 3. Пытаемся снова провести этот же документ 4. Вылазит ошибка (current transaction is aborted, commands ignored until end of transaction block...)
удалось воспроизвести следующее: журнал документов Складские документы -> перемещение ТМЦ(в розницу) (не проведен) провести -> --error: SQL State 25P02 Native 7 Message ERROR current trans.is aborted... Error while executing the query -- --error: Невосстановимая ошибка бд! -- ->вылет 1С либо если сделать документ непроведенным, а затем попытаться провести - результат тот же, с вылетом 1С в трассировке - 1cv7s 8-9 EXIT SQLExecDirect with return code -1 (SQL_ERROR) HSTMT 022D15A8 UCHAR * 0x01EC9D40 [ -3] "Select * from _1SJOURN(NOLOCK) where ROW_ID=?\ 0" SDWORD -3 DIAG [25P02] ERROR: current transaction is aborted, commands ignored until end of transaction block; Error while executing the query (7) в логах сельты: in_sql: Select * from _1SJOURN(NOLOCK) where ROW_ID=? out_sql: SELECT * FROM _1SJOURN WHERE ROW_ID=?
А если: документ открыть из журнала (журнал содержит перечень документов, количество строк больше 0); добится ошибки при проведении документа (журнал не закрывается). После этого журнал документов будет содержать 0 строк... Если у вас эта ситуация не повторяется, то у нас она наблюдается на нескольких базах (из 35 переведенных - остальные просто еще не проверяли, но я думаю, проблема та же). Возможно проблема в этом... Я в понедельник Вам пришлю лог самой селты, только у нас разница -7 часов (соответственно рабочий день уже почти закончится)
(In reply to comment #2) > А если: > документ открыть из журнала (журнал > содержит перечень документов, количество > строк больше 0); > добится ошибки при проведении документа > (журнал не закрывается). > > После этого журнал документов будет > содержать 0 строк... воспроизвести не удалось (selta v1.0.3) - не удалось добиться ошибки проведения с очищением списка документов в журнале. с selta v1.0.4 ошибка(описана в комментарии #1) возникает при перепроведении (с вылетом 1С); если же 1С открыть повторно - новый документ существует и отмечен проведенным
частично удалось воспроизвести, selta v1.0.4, 1с+ТИС (стандартная), журнал "складские документы"->открыть непроведенный док.(который и не проведется)->попыт.провести->ошибка-> a) если, не закрывая, этот же документ записать->журнал очищается; б) если, не закрывая, попытаться повторно провести документ - 1с вылетает ошибку при изменении времени воспроизвести не удалось; если создать чек, потом создать чек на возврат, провести чек, затем попытаться провести чек на возврат - не проводится, 1с выдает ошибку с уникальностью ( "parent__1scrdoc" ) и вылетает
ошибки вылета 1С, очищения журнала и изменения времени воспроизвел, получил логи трассировки, выложил на ftp://tmp/goga/dup_logs/
(In reply to comment #5) > ошибки вылета 1С, очищения журнала и > изменения времени воспроизвел, получил > логи трассировки, > выложил на ftp://tmp/goga/dup_logs/ > скорее всего, проблема с динамическими курсорами. в comm логе часто есть типа "cursor is open" либо "курсор не существует"
То, что написано в комментарии #4: a) если, не закрывая, этот же документ записать->журнал очищается; б) если, не закрывая, попытаться повторно провести документ - 1с вылетает все это происходит из за отката транзакций. (SQL_ROLLBACK) и а) и б) Курсоры закрываются, но ни ODBC драйвер (ни похоже( не уверен) 1с) об этом не знают. по б) Могу сделать так, что бы не закрывалась, путём создания курсора при отмене транзакции. Но все равно происходит то, что написано в (а). Если все-таки вывести ещё раз - вылетает
С последнего раза произошли изменения. Теперь, я могу другими способами сделать некоторые улучшения: схема работы 1с выяснилос такая. 1. Создали Handle подключения 2. Создали Handle операции 3. В этой операции выподняет "SELECT ..." 4. делает ROLLBACK подключения при этом все остается нормально. 5. делает ROLLBACK подключения. 6. Закрывает при этом операцию. Закрывается курсор. Я сделал так. после ROLLBACK, но отменил закрытие курсора (SQLFreeStmt). При этом в отличии от прошлого раза все продолжает работать. Ошибок не возникает. Но курсор без нового создания все равно не работает. Из за этого обидно пропадают с экрана записи. Но при дальнейшей работе с ними, курсор нормально обновится. Надо бы самому его обновить. Но пока не понял когда и в каком месте.
Сделал что бы все работало. В принципе лекарство универсальное. Но может для других баг понадобятся корректировки. Что сделал: 1. Отловил все курсоры окрытые во время ROLLBACK'а его подключения. Изменил тип этих курсоров с SQL_CURSOR_DYNAMIC на 8(их всего 2). 2. В SQLFetchScroll отловил курсор с типом 8. Создал его, заменил тип обратно на SQL_CURSOR_DYNAMIC. Все заработало.
>7. Заходим в журнал документов (в нашем >случае журнал чеков) и пытаемся: > а. Изменить время документа (ошибка duplicate >key constraint "parent__1scrdoc") Снова появилась ошибка, но после нескольких изменений, а не сразу.
Проблема в том, что курсоры даже при окончании транзакции, уничтожаются не всегда. В мануале к посгресу: WITH HOLD specifies that the cursor can continue to be used after the transaction that created it successfully commits. При COMMIT они не должны уничтожаться, и не уничтожаются. А при ROLLBACK. Я из этого не понял. Как бы узнать, от чего зависит, уничтожаться ли курсоры? Надо почитать еще логи. Но пока могу порадовать, я при ROLLBACK'е уничтожаю все курсоры. И пока все работает. Надо завтра повнимательней потестировать.
Всего имеется две ошибки. Обе проявляются при изменении времени непроведенного документа 1. duplicate key violates unique constraint "parent__1scrdoc" parent__1scrdoc индекс таблицы _1scrdoc. Составной. Интересующие нас поле: CHILD_DATE_TIME_IDDOC изменим время документа 9Z. В таблице видим поле: "200810247JT8IO 9Z " Которое сотоит из '20081024' -- дата загадочного 7JT8IO - я так понимаю -- это время. и ' 9Z ' -- это id документа. Что делается: mssql Update _1SCRDOC set CHILD_DATE_TIME_IDDOC=SUBSTRING(CHILD_DATE_TIME_IDDOC,1,8)+'885V5S'+SUBSTRING(CHILD_DATE_TIME_IDDOC,15,9) where CHILDID=? pgsql UPDATE _1SCRDOC SET CHILD_DATE_TIME_IDDOC = SUBSTR (CHILD_DATE_TIME_IDDOC, 1, 8)+'8FUKKW'||SUBSTR (CHILD_DATE_TIME_IDDOC, 15, 9) WHERE CHILDID = E' 9Z ' И ожидаем получить '200810248FUKKW 9Z ' 20 символов. Но получаем: "20081024 8FUKKW 9Z "(53 символа) А тип поля mchar(19) и остается там: 20081024 так, что остается. А там уже такое есть. Дело в том, что SUBSTR, когда входной параметр поле добавляет пробелы. 2. Вторая проблема с курсорами, что они не всегда закрываются, при ROLLBACK. 1. Делаю вместо SUBSTR -- CAST(SUBSTR 2. Принудительно стал закрывать курсоры Но решив только вторую проблему, я перестал сталкиваться с первой, но только в новых базах. А в старых сталкиваюсь. Но не знаю почему. Надо протестировать на только что созданных базах. Только первое обновление. А потом первое и второе. Может хватит и одного!? 1. /var/ftp/tmp/stas/Test1 1+2 1. /var/ftp/tmp/stas/Test2
С обновлением 1 конфигурации ТиС и Бух работают нормально. С обновлением 1+2 работает только ТиС.
Оставляем первый вариант, он идет в сборку.
Добавил второе исправление (с изменениями substr), только другой вариант. Теперь должно все работать нормально. Лежит в current
Created attachment 1016 [details] скрин ошибки postgre 8.3.5 selta 1.0.5 только скачал, вылетает с той же ошибкой... Скрин прилагаю...
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.
