1С 7.7 ТИС ДБФ УРИБ 40 юзеров.

В понедельник вообще с утра работать не могли. И так почти полтора часа.
Только когда я стал по очередности выгонять всех ввидимо отцепилась блокировка и
и все наконец заработали.

Заметил что 3 варианта блокировок:
1. при обмене урбд, попытка захвата доступа к 1SUPDTS
2. При попытке создать новый документ - попытка захвата 1SJOURN
3. При поытке создать элемент справочника - попытка заквата SC214 или 1SDNLOCK
3.1 Блокировка 1SDNLOCK возникает и при создании нового документа (видимо из-за нумерации что ли)

Ну с обменами не так часто и понятно потому что обмен я вижу.
С остальным все на так ясно.

Базы не малые, регистр RA328 подходит к 1.7 ГБ
Я так понимаю что многие проблемы из-за проведения документов задним числом ну и перепроведения если надо
Время ожидания захвата БД сброшено в ноль у всех вроде бы, но уточню. Может кого прозевал.
Заметил что в понедельник много потому что делают много приходов и в пятницу тоже.
Причем всем надо с утра.

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

Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
Тогда бы можно было его притормозить а другие бы работали дальше !!!

(645) Смотря что ты хочешь поиметь с этого архива
Одно дело, если он нужен только для "разбора полетов" за конкретные дни, тогда и твоя схема покрывает это нормально
Другое дело, если ты какую статистику хочешь по ним собирать за произвольные периоды, тут уже варианты есть разные...
можно и отдельную базу для этого держать
И про вот это: " (тогда ТЧ опять в строках неограниченной длины)" - забудь ты уже как страшный сон.
ТЧ для справочника - это подчиненный справочник.
За строки неогр. длины - руки надо отрывать, особенно пейсателям типовых, которые напихали такой байды в Платёжные поручения и хранят там километровые бесполезные портянки. У некоторых клиентов файл BLOB в разы превышает размер файла с проводками

(645) Вон в (646) послушай умного человека, он на этом деле такую собаку съел, что Павлов нервно курит в сторонке)

(646) А она как к базе 1С цепляется?

(649) Да это было бы замечательно, хотя 1С может взять через sqlite большие объемы данных?
Можно было бы конечно в DBF но чего-то я не стал - по-сути надо таблицу где шапки и таблицу где табличные части обычные и табличные части разбухтовки.

Не получилось на 10 дней переделать - регистр заявок хоть изначительно позже чем раньше - но вылетел за 2 гб.
Можно конечно закрывать этот регистр последовательно по годам тогда проблема бы решилась

(646) Да, причем безшовно. C 1sqlite можешь подцепить внешнюю базу sqlite3 и в одном и том же запросе обращаться и ко внешней базе и к базе 1С.
А во внешнюю базу можешь записывать внутренние идентификаторы из 1С и при запросе их типизировать в свою баз 1С.
(650) Что значит большие объемы данных? Максимальный объем базы sqlite3 громадный - 140Tb и 1С тут совсем ни причем, от 1С это не зависит.
А если открывать базу не в памяти ОткрытьБазу(":memory:"), а в файле, общее потребление памяти для запроса может быть значительно больше оперативной памяти 1С. Ну а если подразумевается что итоговый результат больше чем памяти в 1С, ну тогда конечно обрушится.
По скорости примерно так: 272621 записей (xml`ки егаис), средний объем записей 2740 байт, чтение со скоростью ~260 мбпс
В принципе 35% скорости в + подтверджается: https://www.sqlite.org/fasterthanfs.html

(651) А тебе точно нужен 3х валютный учет? Я давно вырезал... Ну и подрезать размеры числовых полей тоже можно.

(651) А, управленчкая, бухгалтерская а еще какая? Нет, 100 лет не нужен.

(652) Ну я прикинул - за 5 лет примерно 800000*5=4000000 записей. Врядли больше

(655)+ 1 таблица шапки и две таблицы табличные части увязанные с шапкой по ключу. Единственный момент - я же сейчас пишу в файлики списокзанчение и две тз но при этом вся номенклатура хранится как номенклатура и т.д., то есть как бы в естественном виде. А в таблицах внешних это уже будут коды наименования и т.д.

(655) sqlite все равно будет сколько записей.
Только учти следующее:  для объемных данных, у меня это xml-егаис делается отдельная таблица Хранилище с полями - ключ и значение, ключ должен быть описан явно, т.к. rowid при vacuum слетает. И отдельная таблица с твоими параметрами для поиска и со ссылкой на Хранилище. Это если сырые данные хранить.
А если как (656), то это не сильно отличается от принципа работы с 1С. Таблицы и таблицы... Разве что наименование в sqlite можно компактнее хранить.

(657)+ так может мне лучше просто через 1с сделать пока что? А попутно поразбираться с sqlite. Просто у меня так файлики мизерные я их и из магазинов для надежности копирую в папки в ЦБ. А ДБФ получается, хотя можно просто копировать их как-то отдельно зато все из одного места а то сейчас у меня архиы чеков - это тысячи небольших файликов с информаицей из 1С. Там нет по-сути никаких индексов, ищется медленновато

(650) может. и в дбф может (ограничивает-то размер всего лишь система блокировки, а не сама структура дбф)
другое дело, что через иксбэйс можешь только монопольно файл открывать. а открывая-закрывая, получишь блокировки похлеще. ну а работая через фоксовый драйве - сможешь,Ю но почему б тогда не чере 1склайт?

(658) ну так это считается элементарно: размер записи умножить на количество :-)))) меньше 2г - в справочнике, больше - во внешней базе

(659) Так уа уменя же все это пишется при закрытии кассовой смены - работает один юзер - откуда блокировки возьмутся. Я учет работанков склада веду в 2 ДБФ. Чищу изредка предыдущие годы и веду потихоньку при закрытии смены и они тоже апдейт. Просто учет работы склада (время и т.д., кол. собранных строк) начался лет 5 назад а архив чеков с 2005 года а то и раньше

(661) "каждый - сам кузнец своего геморроя!"©

(662) ДА логика простая - у меня впн - получается общая для всех точек сеть и удобно при закрытии смены в свою папоску файлик с чеками за день записать и тут же скопировать по сети этой в папку соответствующую на ЦБ. Руководство часто смотрит отчеты по куче магазинов сразу в ЦБ - и тогда это очень удобно, а с ДБФ уже так не получится хранить дбф по дням - это глупо

(658) Зачем тогда спрашивал? Ты же знаешь первое правило - "Работает - Не трожь"!
Сделай параллельно для теста.
А вот 1000 небольших файлов это ЗЛО, 1С это перевариваривает, действительно, слишком медленно.

(664) Правильно спрашивал. Чтобы как раз спросить про вот это дело. Может через фтп их отправлять заменяя те что есть каждый раз?

(664) sqlite - базу тоже надо ведь архивировать. А я даже не пойму где она хранится-то и как

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

никак не получается понять когда call bat1 call bat2 в файле bat3.bat выполняются одновременно а когда последовательно.

(667) ping -n 10 -w 20000 <несуществующий в твоей сети адрес>

(668) То есть при этом второй батник будет выполняться или же только после пинга? Мне-то надо чтоб понять они параллельно выполняются

(669) Ты просил длинный батник )))
А там сам проверяй...

(670) ну это да - в миллисекундах спасибо

Обрезал иротги по заявкам жа с 2016 года. Но регистр итогов заявок изменился только на 15 мб, с 918144 до 903115 мб
А ведь я закрыл регистр заявок полностью на 30.06.2020. И там десятки тысяч таких заявок закрытых теперь

(672) Нулевые из регистра удалил?

(673) Удалил обработкой что мне Злопчинский дал

Обработку смотрел - вроде как работает правильно исходя из ее текста

(673) + Упаковку таблиц ИБ после?

(676) Да и переиндексацию обязательно. Но это регистр итогов (заявки), который с начала базы и не закрывался толком. Вот теперь я его закрыл до 30 июня 2020.

(677) Закрытие закрытию рознь.
Насколько размер *RG твоего "закрытого" регистра отличается от его *RA?

(678) RA 116 mb, RG 903,101 mb
Регистр остатков больше регистра движений потому что долго не было закрытия. Но вот сегодняшним днем же закрыл

(679) Сегодняшним закрыл. А старые периоды так и висят открытыми... Вот если бы ты закрывал последовательно - удовлетворили заказ - в тот же период и закрыл. А то у тебя картина с размерами - ненормальная.

(680) Я согласен но вот так получилось. Теперь контролирую. Просто надо этот регистр по возможности как-то еще уменьшить. Можно как-то? А то ситуация можно вылезти сильно плохой и без регистра движения партий

(681)+ В конце концов заявки покупателя которые неподтвержденные - можно в итогах спокойно убить вообще правда до 30.06.2020

(672) если ты закрыл - то у тебя уменьшится только на сейчас. а все хвосты которые тянулись несколько лет - ника кне изменились, поэтому закрытие длао маленький эффект. если бы ты сделал помесчное закрытие неактуальных заявок последним днем месяца, то получил бы в итоге намного более ощутимый выигрыш. потому что не тянулись бы хвосты постоянно.

вот в (680) то же самое сказали

(681) если история заявок не интересует - можно тупо порезать движения и итоги по "неактуальным" заявкам, например на 01.07.20

(685) А та обработка что ты мне прислал может так сделать? Или это надо еще что-то? В-принципе может сверну и перед созданием перифериек сделаю помесячное закрытие с переносом итогов - долго будет, но все равно так лучше. Ну может не помесячно а поквартально уже бы было хорошо

(686)+ Поулчается что для меня неактуальными являются те заявки которые раньше 01.07.2020 и к сегодняшнему дню они незакрыты. И обрезать их надо конечно так чтоб обменов не было, то есть прямыми запросами на каждом магазине отдельно

есть у меня обрезка регистров заявок. ща гляну.
отослал

(688) спасибо

Пытаюсь заменить транзакцию попыткой. Но у мнея почти явно начать транзакцию и нет. Не нравится когда несколько операций с документами в одной попытке - как-то криво получается. Сложно понять куда наверх уходить. Благо что почти все в ПриЗаписи так что можно уходить прямо на СтатусВозврата(0) и ничего по идее ужасного не случится

"Не нравится когда несколько операций с документами в одной попытке - как-то криво получается."
ну как написано, так и получается ;-)

(691) "чем удобряли - то и выросло"©

икс = 0;
    игрек = 1;
    зет = 2;

    Сообщить("икс игрек зет "+икс+" "+игрек+" "+зет);
    
    попытка
        икс = икс+1;
        игрек = игрек+1;
        зет = зет+1;
        зет = зет/0;
    исключение
        Сообщить(ОписаниеОшибки());
    КонецПопытки;

    Сообщить("икс игрек зет "+икс+" "+игрек+" "+зет);

(690) ты, главное, не путай транзакцию и попытку...
по идее ситуация как в примере выше - будет отрабатывать и при работе с документами...

(694) Теперь не попутаю. Мне такой ликбез провели на эту тему серьезный.
Как раз не в попытке а в транзакции у мня несколько операций с документом. Попыток у меня вообще мало
где есть. А вообще считал что это почти тоже что транзакции. Жуть. Что значит экономический программист.
Ну теперь вот не совсем уже

(695) "Погромисты 1С"
то же самое что
"на работу на склад требуются крадовщики и товароеды"

(696) Точно. Но вот все же функционирует, денежки выручаются себестоимость примерно по строительным делам ну и по оптовым накладным считается как-то ну и т.д. Считаю что в определенном смысле программист себя окупает. (О присутстствующем не говорят:) )

да похрен окупает или нет.
у меня есть мое чувство прекрасного. пока оно не начинает возмущаться - я работаю...

(698) Да мне как-то проще отчетность сдать хотя и этого я не люблю. Но что делать - партия сказала надо комсомол ответил есть :)
сайт так сайт мобильный продавец так продавец
Главное чтобы по космосу ничего делать не заставили :)

Насколько помню Транзакция и Попытка друг в друге плохо дружат.
Если Попытка внутри Транзакции неудачная, то и вся Транзакция отменяется (или наоборот, не помню уже - давно было).

нормально они дружат.

(701) НачатьТранзакцию пытается заблокировать журнал(как я теперь понял), не знаю мне кажется что попытка и начатьтранзакцию все-таки плохо совмещаются по крайней мере в моей голове

(702) Тут вопрос в том что при ОтменитьТранзакцию не происходит выполнения ЗафиксироватьТранзакцию. То есть если на НачатьТранзакцию система показала большую фигу то в ЖР пойдет красная запись об ошибке. Если сначала Попытка а потом НачатьТранзакцию то при невозможности ее начать по исключению будет откат наверх. А если сначала НачатьТранзакцию а потом попытку то получается что чего-то пытаешся в начавшейся транзакции но непонятно куда уходить тогда по исключению получается опять внутрь транзакции или в исключение ставить ОтменитьТранзакцию? Короче малость туманно

(702) кроме журнала еще много чего может быть заблокировано.

(704) Ну это да. Но речь о том что во что обертывать и надо ли это. Транзакцию в попытку или попытку в транзакцию?

(705) смотря что надо сделать....

(706) Например? Вот просто хочу понять. ну скажем формирую я массово какие доки - например РКО по премии по сотрам. Юзеры другие работают ддокументы проводят всякие - вот как здесь правильно когда в цикле РКО создаются? НачатьТранзакцию перед циклом? И нужна ли здесь попытка и где?

(707)+ Мне кажется так. Если документ проводится очень быстро то создать полсотни проведенных доков это фигня, а вот если не очень быстро тогда лучше паузы с попыткой опять провести данный документ чтобы другие могли работать в это время тоже

(702) "НачатьТранзакцию пытается заблокировать журнал"
- нет.
откуда в самом начале транзакции транзакция знает какие объекты в ней будут юзатся чтобы их заблокировать?

(703) нормально там все уходит/приходит. аккуратно писать и все.

(705) НачатьТранзакцию ничего не блокирует.\Поэтому ситуация когда рухнет именно на НачатьТранзакцию - представляется мне ооочень маловерятной. Рухнуть при начале транзакции может тогда когда внутри открытой транзакции ты попытался взять заблокированный объект - тут транзакция твоя и навернулась. Но именно на попытке взять заблокированный объект. Но не на "НАчатьТранзакцию".
.
могу конечно ошибаться.
пусть спецы меня поправят содержательно

(707) "например РКО по премии по сотрам." неудачный пример. это явно можно сделать вне рабочего времени. даже не роботом.

(707) нахера в этом примере транзакция? Премия Петрова (РКО на премию ПетровУ) зависит от премии Сидорова (от РКО на Сидорова) что ли?
.
закрутил цикл. в цикле захерачил Попытку на каждый документ (будет медленее чем без попытки). Если создаваемый документ свалился в исключение - да и хрен с ним, пропустил, подождал и дальше херачишь (можно попытку вне цикла, а по исключению - переход на голову цикла к продолжению работы).
.
в результате сгенерил не 50, а 47 доков. ну и зашибись. следующим проходом (через час или как-то же ты понимаешь что РКО у тебя еще не созданы) сгенеришь оставшиеся 3

(713) Ну на самом деле так и есть. Ну а что тогда делает НачатьТранзакцию? Она же объявляет всем что будет что-то писаться в базу данных?

Написал для этой проблемы следующий слоеный пирог:
1) Сервис сообщений и регистрации подписчиков на сообщения.
2) Внешнюю компоненту для приема сообщений с этого сервиса - технологии COM.
3) Консольную утилиту с командами "109" - выйти немедленно всем, "107" - остановить работу и "108" - продолжить работу.
4) Ввел глобальные переменные - как "параметры сеанса", типа можно работать или нельзя.
В момент когда начинался обмен УРБД - отправлял из скрипта (обмен автоматический) 107 и все клиенты изменяли значения параметров сеанса. Когда кто-то из них пытался сделать запись в базу данных, до того, как произойдет блокировка, проверялось при помощи этих параметров: а не начат ли УРБД обмен, и если начат - вываливалось модальное окно, блокирующее его работу. Затем обмен кончался, всем отправлялось 108 и люди продолжали работать.
5) Настроил Formex.dll на события открытия форм и прописал логику, критическую к блокировкам.
6) Настроил глобальные вызовы ПриЗаписи, ПриОткрытии, ПриСозданииНового, ПриВводеНаОсновании при помощи ActiveMD - зашел во все формы всех метаданных и расставил процедуры.
7) Работает уже более 10 лет.

(715) Интересно, собственно я об этом и говорил все время
Правад вот насчет написания внешней компоненты - сложно это )

(711)
«пусть спецы меня поправят содержательно»(с)
Открой, наконец, файл «ПроТранзакции.odt».
Я это написал специально для ТЕБЯ в январе 2019 года.
А если лень открывать, то читай тут:
=====================================
Положение № 1.
Транзакции запускаются/активизируются:
1) Явно, оператором языка 1С НачатьТранзакцию().
2) Неявно, в модуле проведения документа.
3) Неявно, в любом операторе языка 1С вызывающем модификацию таблицы БД. Например: Новый(), Записать().
Положение № 2.
Вложенные транзакции являются фикцией - на "поведение" блокировок они не влияют. Реальной транзакцией является транзакция "верхнего" уровня.
Положение № 3.
Блокировки накладываются на всю таблицу, а не на отдельные записи таблицы.
Положение № 4.
При выполнении операций внутри транзакции чтения или модификация (изменение записи или добавлении записи) "возникают" следующие блокировки:
1) До первого оператора обращения к таблице никаких блокировок не накладывается.
2) При (перед/до) выполнении первого оператора чтения таблицы накладывается блокировка по записи.
3) При (перед/до) выполнении первого оператора модификации таблицы накладывается блокировка по чтению (или подымается уровень с "по записи" на и "по чтению", если чтение таблицы уже было ранее в этой транзакции).
Положение № 5 (спорное).
Первый оператор (по логики алгоритма) языка 1С выполняющий обращение к таблице внутри транзакции "возбуждает флаг" т.н. "групповой блокировки". Основное назначение этого "инструмента" - запомнить имя таблицы, используемое в выдачи "системного" сообщения о невозможности начать очередную транзакцию. Думаю, что по задумки разработчиков 1С-а этот "флаг" должен обеспечить последовательное выполнение транзакций в различных сессиях 1С. Данная задумка сможет работать, если разработчик на языке 1С будет во всех транзакциях придерживаться единой последовательности в алгоритме на порядок  обращения к таблицам. Примером успешного срабатывания данной задумки - модуль проведения документов. Т.к. такой "первой" таблицей является "Журнал документов" для всех видов документов.
Положение № 6.
1) Операторов модификации БД вне транзакции не существует в 1С (см. пункт № 3 в положении № 1). И если выполняется модификация таблицы БД этим неявным способом активизации транзакции, а таблица заблокирована в транзакции другой сессии 1С, то операция модификации сваливается "мгновенно" и настройка "Время ожидания захвата таблицы..." на это не влияет.
2) Чтение вне транзакции не накладывает никаких блокировок. Но, производится проверка блокировки таблицы по чтению сделанная из транзакции другой сессии 1С. И если таблица заблокирована модификацией в транзакции другой сессии 1С, то данное чтение перейдёт в длительное ожидание не зависящее от настройки "Время ожидания захвата таблицы...".
Положение № 7 (общее).
В 1С 7.7 DBF-ая версия обеспечивается на 100% требования ACID (SQL-ная не обеспечивает). Т.е. все изменения выполняемые в транзакции "нашей" сессии не видны в других сессиях и не могут изменится другими сессиями. В "нашей" сессии повторное чтение данных не даст разный результат (если не использовать прямые запросы на FoxPro). Но, существует проблема не "описанная" требованиями ACID. Это случай когда две разные сессии читают данные и на основании их анализа делают выводы о дальнейшем поведении алгоритма. Если не выполнить блокировку по чтению всех читаемых данных, то сессии будут делать вывод на основании информации, которая может быть изменена в другой сессии уже после выводов сделанных в "нашей" сессии. Классический пример этой ситуации - обновление итогов:
1) Читаются данные в оперативную память (переменная Х) старого значения итогов.
2) Выполняется Х=Х+Добавка.
3) Записывается Х в базу данных.
Если одна сессия выполнит пункт № 1 до выполнения пункта №3 в другой сессии, то итог будет неверным. И транзакции 1С никак не решают эту проблему. Кроме обеспечения инструмента "флага", как это существует при проведении документов.

Вопрос к участникам темы.
Ниже привожу код из глобального модуля.
Возникала ли проблема в вашей системе решаемая подобным кодом?

//--------------------------------------
Процедура ШальнаяТранзакция()
   Пока (0=0) Цикл
      Попытка
         ОтменитьТранзакцию();
         ЗаписьЖурналаРегистрации("Шальная транзакция: "+ИмяПользователя(),,,,5);
      Исключение
         Прервать;
      КонецПопытки;
   КонецЦикла;
КонецПроцедуры
//--------------------------------------
ОбработкаОжидания("ШальнаяТранзакция",1);
//--------------------------------------

(717) То есть если я выбираю ВыгрузитьИтоги или РассчитатьИтогиНа или По то в таблица регистра которую я анализирую или даже несколько таблиц регистров - блокируются и по записи и по чтению? И тогда чем хуже закрыты регистры тем больше времени требуется на чтение итогов?

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

(713) премиальный фонд вычисляется по объему продаж за педыдущий период , насчитанному ровно в 16:28:37 четверга четной недели, следующего за отчетным периодом; и распределяется по отделам, а внутри отделов по сотрудникам методом Монте-Карло.

(721) Да нет у нас такого фонда давно, я просто пример привел. Вот из (720) какая транзакция отменится? Ведь есть же транзакции блокирующие и по записи и по чтению (самый высокий уровень), при этом транзакционные операции производятся как с документами так и со справочниками. При этом блокируется или Журнал или днлок или упдтс кстати больше и не помню никаких других вариантов блокировок когда ошибки в ЖР пишутся

(716) Если интересно, то могу все передать.

(716) Интересно даже очень. А это для ДБФ или без разницы?Я хотел на почту написать но у вас она скрыта

(714) "Ну на самом деле так и есть" - премия одного сотрудника влияет на премию другого сотрудника?

(720) " Тогда какую транзакция отменяет ваша процедура ожидания каждую секунду?"
скорее всего, это подстраховка от повисшей незакрытой транзакции где-то (только транзакция открытая в своем сеансе?)
.
а вот действует ли ОтменитьТранзакцию() на открытые транзакции которые были открыты в других сеансах? - вот не знаю.
по здравому размышлению - ОтменитьТранзакцию действует только на транзакции своего сеанса..

(723) и мне можно прислать? e.meil@mail.ru

Кстати.
у  hogik есть весьма полезная приблуда, которая позволяет тормознуть 1С в тот момент когда нет никаких транзакций

(728) Какая?

(726) Транзакции именно своего сеанса. И как бы теперь более менее понятно что к чему

(720) (726)
В сообщении (43) написано:

«Или кто-то долбит документы а все стоят, а долбит впустую ибо один вид дока наезжает на другой. Увидел это - тут же его отключил и все заработали. Но как сделать чтобы аж визжал комп и ругался что Сидоров лупит черт что в одиночку»(с)

Допускаю, что в сессии «Сидорова» образовалась незакрытая транзакция (на уровне движка БД) из-за сбоя в неком алгоритме. И последующие транзакции выполняются как написано в положении № 2 сообщения (717), давая возможность работать «Сидорову» в диалоговом режиме. Тогда код из (718) сообщения может решить проблему.

(731) " образовалась незакрытая транзакция (на уровне движка БД) из-за сбоя в неком алгоритме. "
-то есть тутречь о том, что именно прогрраммистом открытая транзакция где-то незакрывается..
но вроде как если форму закрыли или процедура, в которой открыта транзакция заканчивается - выход из процедуры - то транзакция должна закрыться или отмениться автоматом.

(732)
Должна. :-) Но, я написал выше «из-за сбоя в неком алгоритме»(с). Я вспомнил, что за 15 лет эксплуатации мы имели пару похожих случаев, как описывает Юрий. Причину мы не смогли найти. А у Юрия, по его словам, это возникает раз в три месяца. Те. разглядывая журнал событий, можно будет попытаться найти «точку» в действиях пользователя/системы с которой пошла эта бяка.
Это если код из (718) сообщения сработает. Ну, и автоматизировать снятие проблемной сессии без ручных действий.

(732) Понимаешь - вся идея открытой мной ветки заключалась именно в том чтобы
1. Понять вот все эти сбои - это следствие каких-то моих устанвок типа "секретных" релизов или патчения каких-то библиотек, либо падения периодического - журнала или же это вполне объяснимые и даже управляемые в рамках штатной (или с добавлением формекса) 1с и тогда вопросы в скорости проведения документов, тормоза из-за незакрытых регистров и т.д.
2. Чтобы все-таки отделить транзакции от попытки - у меня это понятия смешивались в голове как-то.
3. .....Что-то еще попутно узнать и применить типа кэш по константам.

Я получил очень сильную серию консультаций (даже где-то натаскиваний) от hogik. И многое в голове прояснилось. За что я ему очень благодарен!
Ну и массу полезнейших советов и подсказок от остальных форумчан за что вам всем большое спасибо

Просто первые ветки о том что только под скуль можно что-то выяснить по транзакциям - не совсем верные и штатные механизмы платформы 1С и его встроенный язык имеют очень большие и достаточно прозрачные возможнсти которыми в большой степени можно штатно или почти штатно управлять

(734)+ Ну и как я понял - что все-таки при всех нюансах лучше использовать ОбработкуОжидания одну на сенс, тогда все намного прозрачнее ну и обработку внещнего события - тоже одну - и тоже именно в глобальном контексте. Эти же процедуры в локальном контексте мне кажется для таких не очень сложных алгоритмов как у меня - применять не стоит потому что как вообще работает вся эта "адская" смесь глобального и локального контекста особенно в плане когда есть глабальная обработка ожидания (точнее с ипспользованием Формекса - их несколько же можно делать) и обработки ожидания из локальных контекстов. Конечно в этом случае глобальная процедура ожидания - штатная - получается довольно сложной и длинной но тут уж ничего не поделаешь. Ну и выгонялка пользователей - возможно толкьо с помощью жесткого киллера а до это отправки сообщения во все сеансы

Да, к сожалению бывает такое как описано в (733). Редко, но бывает. Кто-то один работает, но в параллельной реальности т.к. документы у него по факту не сохраняются, а все остальные курят бамбук. Синтетическими тестами добиться такого не удалось.
А вот взаимоблокировки получить - легко! Код, конечно идиотский, но зато одна сессия четко залипает на захвате таблицы Журнала, а другая на Номерах документов.

Процедура СоздатьВзаимоблокировки()
  Система=СоздатьОбъект("Система");
  НачатьТранзакцию(); // без этого взаимоблокировки не будет!
  Для ии=1 По 100 Цикл
    Состояние(ии);
    Попытка
      ОтменитьТранзакцию();
      Сообщить(1/0);    
    Исключение
      Попытка
        НачатьТранзакцию();
        Реализаиця=СоздатьОбъект("Документ.Реализация");
        Реализаиця.Новый();
        ОтменитьТранзакцию();
      Исключение
      КонецПопытки;
    КонецПопытки;
    Система.Уснуть(100);
  КонецЦикла;
КонецПроцедуры


(736) И все это в обработке ожидания глобальной должно быть?
Каждую секунду будет запускаться?

(737) Во внешнюю обработку засунь. И запусти в 2х сессиях. Честно говоря не очень понимаю как это работает, но обе сессии зависнут.
Это не лечилка от hogik, это наоборот - убивалка!

(738) Я понял кадется. Это как пример вот такого поведения базы как я описывал

8 страниц ни о чем ... Ау Ромикс ты где?

(740) ромикса похитили инопланетяне с Нибиру за разоблачение эфирно-кефирного заговора мирового правительства иллюминатов. Только тс-с-с!

(741) А ведь тебе не платят за забалтывание и сокрытие сведений о деятельности верхушки глобального управления. Зачем ты льёшь воду на их мельницу?

(742) это не вода! :-)

(743) Главное - после того ка котлил - не забыть про ширинку...

(740) Еще как о чем!

Ведь здесь по-сути вообще затрагивались как практические так и теоретические основы работы с транзакциями
и способы устранения ошибок и способы корректного управления транзакциями

(745)+ Я например набрался наглости и некоторые проблемные места уже проработал и кое-какие задачки
за которые никак не мог взяться потому что висело мое непонимание всех этих вещей надо мной дамокловым мечом