Bug 3459

Что-то я не смог повторить. 
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.
> Непонятно, почему считалось, что их не надо
> обновлять. Очевидно надо. 

Сделал что бы обновлялись курсоры при всех этих вызовах. Все работает.