Всем доброго дня!
Возникла проблема, не знаю как решать.
В программе иногда возникают документы у которых в журнале стоит флаг проведения и история изменений документа показывает, что этот документ был проведен, но нет движений ни по одному из регистров. При любом перепроведении документов хоть интерактивном, хоть программном движения появляются. Проблема давнишняя, программа иногда может месяцами работать нормально, а потом возникнет несколько таких документов.
Может наоборот - наблюдаться каждый день, но по нескольким документам.
Боролся с ней так: утром каждого дня автоматическая обработка проверяет все документы реализаций предыдущего дня на наличие движений по регистру остатков. Если документ числится проведенным, а движений по остаткам в регистре нет, то перепроводим документ. А тут за вчерашний день таким образом выявилось порядка 50 таких документов. Какие у кого есть мысли из-за чего такое может быть? В день в программе оформляется около 1000-1200 документов.

Обмены есть?

Помню была такая проблема, вставлял проверку - через FormEx ловил событие (то ли ПослеЗаписи, то ли ПослеПроведения уже не помню) и прямым запросом проверял наличие движений по регистру.

Обмены с периферийными базами раньше были, тоже на них грешил.Но теперь уже больше полугода перефериек не осталось. А проблема продолжается. Думал ещё на параллелизм, убрал его, но не помогло. Сервер SQL 2000 стоит с которым все вроде должно работать.
(1) Про какие ещё обмены речь?
В общем-то обменов много, документы создаются автоматически, но проведение почти всегда интерактивно операторами выполняется.

Движения исчезают у документов, у которых они уже были?

(4) В последний раз именно такое ощущение (хотя не уверен)
Уже вручную сам прогоняю обработку с проверкой за последние два дня. Уверенности нет, но вроде: как вчера прогонял проверку за 20,21 число проблем не было, сегодня прогоняю проверку за 21,22 число - обнаруживаю проблемы с несколькими документами за 21 число.

Сейчас думаю периодически прогонять проверку за текущий день

Основная проблема в том, что это происходит не каждый день, поэтому поймать ситуацию тяжело. В последний раз такое наблюдал с несколькими документами за 25.08, теперь вот выявилось с документами за 21.09. Повторюсь: никакой стабильности нет, ни с чем связать такое поведение не могу.

Точно клюшки ?

(8) 1с77

как вариант, посмотри документы без даты

(0) Фанктест. Тесты надо запускать.
Если выявится док, то в список и перепровести.

(10) Посмотрел журнал в интервале начиная с пустой даты до 50 года. Там документов с пустой датой не увидел. 17 годом есть несколько непроведенных, но с пустой нет

Перво наперво убрать все компоненты.

И озвучить их версии.

(11) по сути так и делаю. Есть обработка которая работает на след.утро она и выявляет, но получается что уже поздно, остатки после перепроведения уже улетают в минус, так как более поздние документы не видят более ранних движений. А потом перепероведение их восстанавливает и мы в минусе

(13)Каким образом они могут влиять на проведение?
В модулях проведения используются только типовые механизмы.
В отчетах и формах документов с помощью 1срр идут конечно выборки через прямые запросы но не записи в документы или в журнал. От туда только выборки. Выбросить 1срр не представляется возможным.

(16) а в журнале есть записи об успешном проведении? или проведение "обламывалось"?

База большая? У меня очень давно такое было, выгрузка и загрузка базы выручала или реиндексация, но не на долго, так и не разобрался с этой проблемой. Была такая ситуёвина, что точно движения по документу были, а через время их нет.

Да, и попробуй проверить саму базу - чекдб, реиндекс (возможно - проверка восстановления из бэкапа) и все такое.

(18) да даже на базе под 160, с обменом с периферийками, еди и мобильной торговлей, такого не наблюдалось... так что размер тут вряд ли...

(0) Тоже бывает такое и на нашей базе, которая ещё до сих пор используется. Наблюдается только в одном виде документов. Такие документы создаются только программно по реестрам. Так вот, изредка появляются такие документы без движений по регистрам, хотя проведены. Перепроводя их любым способом, движения появляются. У нас не критично к следующему дню, поэтому раз в день запускается проверка таких документов и перепроводятся, если что-то возникло.

(16) Любая компонента, написанная кривовато может изменить данные подпортив память. И как сам догадываешся может случиться пшик.
У меня к примеру очищались некоторые справочники. Жутко было.
это на 2000-м серваке. Потом перешли на 2005 сервер и вроде бы все в порядке.

(22) это чтоу тебя так гадило?

(21) Вот и у меня что-то подобное, пока думаю просто увеличить количество проверок. Буду проверять в день по несколько раз.
Размер базы 60Г.
Бэкап несколько раз в день.
Переиндексация идет каждую ночь.

(24) попробуй после создания и проведения фиксировать в логе количество движений документа. определишь по крайней мере, сразу без движений проводится, или они исчезают.

случаем БИ + ОИ одновременно не используется ?

(26) Если БИ -это бухгалтерия, а ОИ - это оперативный учет, то да. В основе лежит типовая комплексная, поэтому используются обе компоненты. С этим что-то связано?

(24) Позвольте поинтересоваться в целях повышения опыта... :)
Зачем SQL базу каждый день переиндексировать?

(28) А на всякий случай, хуже от этого не будет, а в некоторых местах чуть быстрее работать будет.

(25)Какие способы у вас есть предложить отловить момент после проведения?

Я так понимаю, что нужна какая-то процедура которая после проведения документа проверит движения и если их не оказалось, снова проведет документ. Как можно организовать данную процедуру?

(27) этот документ имеет галки проведение по ОУ и БУ ? закинь период БИ вперед и ТА закинь вперед (поставь будущий период поп обеим компонентам) - должно перестать терять движения, встречал такое именно связанное с одновременным учетом в ОИ и БИ именно SQL именно 2000

(32) Закинуть вперед БУ могу, а вот закинуть ТА вперед не могу. (Только если временно, а потом вернуть?). Работаем только по ТА, иначе будут полные тормоза.

(32) Да, документы реализации конечно же имеют движения и по ОУ и по БУ. БУ не проверял, не могу сказать есть или нет проводки.

(32) так с чем такое может быть связано? ибо у меня на комплексных такового не наблюдалось.

(30) перехватчик,  Событие_ОбработкаПроведения(Конт,ДопПараметр)
в ней
рез=Перехватчик.ВыполнитьОригинальноеСобытиеГК(Конт, "ОбработкаПроведения", ДопПараметр);
а после этого - уже можно смотреть движения

(30) ну а если создание, запись и проведение программные  - тогда еще проще...

(35) как раз БИ были менее ТА и он перестал делать движения , если мне память не изменяет, давно это было - в 2004 годе )))

(38) "боже, как давно это было - помнит только мутной реки вода"©

(34) в моем случае есть или нет проводки никак не влияло - влияло то что есть галка БИ на документе и сами итоги отставали от ТА (опять же какие то нюансы были еще с создавать операцию - галкой, тут уже не упомню)

(39) Программа не перестает делать движения. Движения делаются постоянно, 1000-1200 документов. И может полгода работать без сбоев.

+ я так понимаю двигло смотрело на БИ - их нету - создавать операцию нинада - ага ну и значит движений нету и хлобысь - а док проведен )))

(41) в том то и дело - там нюансы какие то с вычислениями - у мну тоже НЕ все документы были без движений, только некоторые, на сам код проведения еще можно было б посмотреть, если память не изменяет - разделили на две процедуры потом проведение по БИ и по ОИ

(30) "Какие способы у вас есть предложить отловить момент после проведения?"
- генерация внешнего события формексом.
у меня так сделана автовыписка счф.

(31) см (44)

    Если  ПустоеЗначение(глСервис) = 1 //нет обработки асинхронных событий
    Тогда
        Возврат;
    КонецЕсли;
    
    //сюда попали если проводим интерактивно
    глСервис.ВнешнееСобытие("FAKIR", "ИЗМЕНЕНИЕОТБОР‡ИЗМЕНЕНИЕРЕАЛИЗАЦИЯ", ЗначениеВСтрокуВнутр(ТекущийДокумент()));
    Если Проведен()=0
    Тогда
        глСервис.ВнешнееСобытие("FAKIR", "ГЕНЕРАЦИЯСЧФВЫДАННЫЙ", ЗначениеВСтрокуВнутр(ТекущийДокумент()));
    КонецЕсли;

КонецПроцедуры //ОбработкаПроведения()

В семёрке была такая засада:
Если мы проводим документ - то он проводится.
Если мы потом его изменяем и сохраняем, а в этот момент происходит ошибка - то в документ записываются новые данные, и он остаётся проведённым, но движения документа остаются старыми.

(46) наверное надо включить призаписиперепроводить, тогда и запись и проведение будут в одной транзакции
??

(31) если проведение происходит из формы документа и используется formex - то проверить движения можно в процедуре ПослеЗакрытия()

(47) нет

(49) непонятно тогда

(0) Модель востановления какая ?

Зачем несколько раз делаешь bacup в день икаким именно способом. И работают ли в это время в базе.Вот это как раз и может влиять.

Аналогично  как делаешь переиндексацию и работают ли в это время в базе. и не путаешь ли ты индексацию с фрагментацией



Ну и скорее всего одно из двух когда возникает subj
1. Из модуля проведения проводишь другой документ
2. в Модуле проведения используешь 1с++ и в нем  некоректно
написано ( а так как некоректность проявляется не всегда ) имеешь subj

(51)
1. В модуле проведения другие документы не проводятся. (Да и тяжело  это сделать штатными средствами если нет чего-то вроде как в (45))
2. 1с++ конечно используется в модуле проведения, но только для выборки данных.

А вот насчет влияния бекапов - не думал. Ночью бекапы делаются, когда люди в базе не работают. А днем естественно в рабочее время. Команда SQL днем:
BACKUP DATABASE [ИмяБазы] TO  DISK = @pathName WITH NOFORMAT, NOINIT,  NAME = N'ИмяБазы', SKIP, NOREWIND, NOUNLOAD,  STATS = 10.
Ночью дополнительно:
EXEC @RC = [ИмяБазы].[dbo].[_1sp_DBReindex]
DBCC SHRINKDATABASE (N'ИмяБазы', 0,TRUNCATEONLY);

(52)
1 вполне делается штатными средствами. ну будем считать что у тебя этого нет.

Шринк вообще убери
не мешай sql работать

про backup ничего не могу сказать потому что
1 ты не указал модель восстановления
2 по тому что не знаю в детадях как эта команда работает

Но вполне возможно что backup накладывает длительную транзакцию из-за которой как раз и происходит subj