Серьезные тормоза (очень серьезные) при отмене проводки как получить: Исходная конфигурация: Демонстрационная Комплексная БД из поставки 1С 1) Выгружаем данные штатными средствами 2) Создаем новую пустую конфигурацию для SQL, создаем БД на сервере через Selta 3) Пробуем загрузить данные из п.1. Выгрузка зависает минут на 10-15. На момент зависания в строке состояния надпись о загрузке "Начисления заработной платы сотрудникам" Далее открыть получившуюся базу. Сменить период расчета ЗП на следующий (предупреждения о неначисленной зп проигнорировать). Ввести документ "начисление заработной платы". Заполнить автоматически сотрудниками. Перепровести несколько раз. Первая проводка - полет нормальный. Вторая - зависает (уже 20 минут работает). Исходя из того, что отмена проводки так же зависает, а при перепроводке эта операция также выполняется (причем первой), логично будет предположить, что тормоза проявляются именно при отмене проводки.
Что-то я не смог повторить. 1. База у меня пустая 2. Сменить период расчета ЗП не знаю как
Поставил ЗиК. Подозреваю, что эффект тот же. Делаю непроведенным, 1с виснет. Точнее выполняет один и тот же запрос Select COUNT(*) from CJ447(NOLOCK) where IDS=? and DATEE>=? and DATEB<=? and ( ( DATEE=? and ID<=? ) or ( DATEE<? ) ) Я так понимаю ждет каких-то изменений. MS делает все быстро.
Не понял что не так. В трассировке проводка занимает 50 000 тыс. строк. Особо не отследишь. Хотя я еще не смотрел, что конкретно он получает в повторяющихся запросах.
Не могу найти создание курсора на повторяющийся запрос: Select COUNT(*) from CJ447(NOLOCK) where IDS=? and DATEE>=? and DATEB<=? and ( ( DATEE=? and ID<=? ) or ( DATEE<? ) ) Может от не создается по каким-то причинам? Зато такой курсор создается все время. Эти запросы выполняются по очереди. SELECT * FROM CJ447 WHERE IDRECALC=? ORDER BY IDRECALC, ROW_ID Но в поле IDRECALC лежат только нули.
Особо похвастаться нечем, кроме наблюдения, что до последнего момента, где все зациклевается все происходит одинаково у posgres и ms sql. Сделал триггер, CREATE TRIGGER MAKELOGCJ447 ON [dbo].[CJ447] FOR INSERT, UPDATE, DELETE AS if exists(SELECT * FROM INSERTED) INSERT INTO LOGCJ447 SELECT *,'INSERTED' FROM INSERTED; if exists(SELECT * FROM DELETED) INSERT INTO LOGCJ447 SELECT *,'DELETED' FROM DELETED; что бы отследить, что меняет 1c в таблице CJ447. Но 1с с ним падает. Почему не выяснил.
(In reply to comment #5) > Особо похвастаться нечем, кроме > наблюдения, что до последнего момента, где > все зациклевается все происходит > одинаково у posgres и ms sql. > Сделал триггер, > > CREATE TRIGGER MAKELOGCJ447 ON [dbo].[CJ447] > FOR INSERT, UPDATE, DELETE > AS > if exists(SELECT * FROM INSERTED) INSERT INTO LOGCJ447 SELECT *,'INSERTED' FROM > INSERTED; > if exists(SELECT * FROM DELETED) INSERT INTO LOGCJ447 SELECT *,'DELETED' FROM > DELETED; > > что бы отследить, что меняет 1c в таблице CJ447. > Но 1с с ним падает. Почему не выяснил. > падает только на постгри? ты его отдельно от сельты делал или в 1с? если в 1с - то может быть потому, что старые сборки сельты не знают что делать с " [dbo].[CJ447] ", умели только " dbo.CJ447 "
Не, триггер я сдеал в MS SQL'е. Все должно быть нормально. Я проверил. В таблицу можно добавлять, удалять, изменять. Но 1с почему-то падает.
воспроизвел и на комплексной, при второй проводке зависает
(In reply to comment #0) > документ "начисление заработной платы". > Заполнить автоматически > сотрудниками. Перепровести несколько раз. > Первая проводка - полет > нормальный. Вторая - зависает (уже 20 минут > работает). что- то теперь не воспроизвелось уже
воспроизводится, в том же варианте, вторая проводка документа "начисление зп"
Виснет после окончания всех действий в процедуре отмены проводки, там вызывается метод ОчиститьДвижения (вроде сам). На нем и виснет. Но это не особо помогло, хотя можно посмотреть все запросы. Но они простые и с ними не должно быть проблем.
есть вероятность что какой-то запрос транслируется неправильно, хотя запросы простые или пробема может быть в курсорах Стас, еще есть варианты?
получил лог сельты... попробую что-нибудь откопать
при зависании процесс постгри что-то делает, видны select, fetch, declare cursor, move, delete, savepoint
(In reply to comment #13) > получил лог сельты... попробую что-нибудь > откопать Там ничего нет. Все запросы транслируются правильно. >при зависании процесс постгри что-то >делает, видны select, fetch, declare cursor, move, delete, savepoint Да в трассировке видно: {call _1sp__1SJOURN_ByIDDOC(' 1H ')} {call _1sp_SC16_ByID(' 1A ')} Select * from CJPROP(NOLOCK) where CJID=447 Select * from CJ447(NOLOCK INDEX=IDRECALC) where IDRECALC='ZIJYGT ' order by IDRECALC,ROW_ID\ 0 Этот запрос готовит но не выполняет. Наверное потому, что в предыдущем ему вирнулось NODATA Select COUNT(*) from CJ447(NOLOCK) where IDRECALC=? and ROW_ID<=?\ 0 Delete from CJ447 where ROW_ID=221 и затем заново. Попробую завтра повторить все, что делает 1с в этом цикле, может найду отличия.
итак ход действий 1с: создаем курсор , в данных имеем 10 строчек, и вызываем SQLFetchScroll с параметром SQL_FETCH_FIRST нужное количество раз вот тут начинается разница между постгри и ms: в ms каждый раз получаем следующую строчку, таким образом перебирая все 10 записей, а в постгри - каждый раз получаем только ПЕРВУЮ, отчего и происходит зависание в постгри каждый раз курсор пересоздается с тем же набором данных, отчего и получаем одну и ту же запись. осталось выяснить, что делает ms с курсорами...
Конкретизирую проблему: Что происходит: ms sql: 1. Открывает курсор (Select * from CJ447 where IDPARDOC=?) 2. Тащит запись SQL_FETCH_FIRST 3. Удаляет запись (Delete from CJ447 where ROW_ID=?) (туже запись) Повторяет 2,3, пока не закончится курсор. pgslq: Все тоже самое, но при повторном (и так далее) SQL_FETCH_FIRST он получает туже саму запись, которая должна была быть удалена. Удаляет ее еще раз, получает "with return code 100 (SQL_NO_DATA_FOUND)" (ничего не удалилось, еще бы уже разок ее удаляли) -- не смущается а продолжает дальше. Курсор само сабой никогда не заканчивается. Я написал тестовую програмку. Записи нормально удаляются, похоже не обновляется курсор.
У нас по каким-то причинам, которые я пока не понял, обновляются только курсоры со свойством : SQL_ATTR_CONCURRENCY SQL_CONCUR_READ_ONLY А тут нету такого свойства у курсора. Надо подумать, почему в SELTA так сделано.
*** Bug 2191 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > У нас по каким-то причинам, которые я пока > не понял, обновляются только курсоры со > свойством : > SQL_ATTR_CONCURRENCY SQL_CONCUR_READ_ONLY > А тут нету такого свойства у курсора. > Надо подумать, почему в SELTA так сделано. Это была неправильная мысль. Свойство SQL_CONCUR_READ_ONLY по умолчанию. Курсор нормально нами создавался, но не обновлялся, обновлялись курсоры только когда вызывается SQL_FETCH_RELATIVE, а SQL_FETCH_NEXT, SQL_FETCH_PRIOR, SQL_FETCH_FIRST, SQL_FETCH_LAST. Непонятно, почему считалось, что их не надо обновлять. Очевидно надо.
(In reply to comment #20) >обновлялись курсоры только > когда вызывается SQL_FETCH_RELATIVE, а SQL_FETCH_NEXT, > SQL_FETCH_PRIOR, SQL_FETCH_FIRST, SQL_FETCH_LAST. > Непонятно, почему считалось, что их не надо > обновлять. Очевидно надо. Сделал что бы обновлялись курсоры при всех этих вызовах. Все работает.
