1с конфликт блокировок при выполнении транзакции как исправить

8

Конфликт блокировок при выполнении транзакции.

(43) SQL profiler без отборов тебе выдаст портянку в подмиллион строк в продуктивной системе, при этом, тормознет ее нехило и с ненулевым шансом, подвесит. Ты репу почешешь и скажешь — не смогла.

А ИР в (24) разбирает гиговые ТЖ за несколько минут, через внешние компоненты, но ты, скорее всего, даже его не щупал.

Поэтому, в список, в список.

Вы особенно и опасны, что извлекаете из себя околоправильные вещи, с умным видом, которые оказываются вредными.

Ищем блокировки

Всем привет! Очередная статья на тему «как мы улучшаем производительность». В данной статье я хочу показать, каким образом можно найти проблемы производительности и понять их причины, имея под рукой голую 1С, 2 руки и текстовый редактор.

0. Описание проблемы:

Итак, задача: наш сырный клиент, 1С:Молокозавод (на основе УПП 1.3), платформа 8.3.8, уровень изоляции транзакций Read committed snapshot . Множество ошибок превышения времени ожидания предоставления блокировки, взаимоблокировок. Особенно во время обменов данными по web-сервисам с некой WMS-системой. Клиент точно не может сказать, в какое время дня возникают проблемы. 1С:ЦУП отсутствует, к тому же, сбор данных ЦУП не желательно запускать более чем на 20 минут, т.к. замедляется работа исследуемой базы и сильно растёт файл данных для анализа, а мы не знаем, когда же нам поймать эти «20 минут». Поэтому мы будем использовать технологический журнал 1С.

1. Настройка технологического журнала

Для тех, кто не знает, на сервере 1С можно настроить логирование многих событий. Создаём специальный конфигурационный xml-файл, помещаем в папку conf сервера и сервер начинает запись логов. Подробнее останавливаться на этом не буду – в моём первом и втором «пятничном» вебинарах я подробно рассказывал о настройке технологического журнала 1С. Итак, включаю технологический журнал (далее – ТЖ) со следующими отборами: отбор по информационной базе, отбор по следующим событиям:

• EXCP – все исключительные ситуации, возникающие в работе исследуемой базы
• DBMSSQL — исполнение операторов SQL СУБД Microsoft SQL Server. Также, ставлю отбор на параметр «lkp» = 1, означающий, что процесс ожидал предоставления блокировки.
• TLOCK -управление транзакционными блокировками в управляемом режиме. Также, ставлю отбор на «WaitConnections» <> «», что означает, что процесс ожидал предоставления управляемой блокировки
• TTIMEOUT — превышение максимального времени ожидания транзакционной блокировки.
• TDEADLOCK – обнаружена взаимоблокировка в управляемом режиме.

События TTIMEOUT и TDEADLOCK появились только в версии 8.3.7 платформы.

Итак, запускаем сбор логов, ставим ограничение, скажем, на 48 часов – платформа будет хранить логи за последние 48 часов.

2. Анализ логов технологического журнала

Через день я начал смотреть, что же у нас получилось:

С 8 до 9 утра было зафиксировано множество событий TDEADLOCK, TTIMEOUT, TLOCK, EXCP.

Пару слов о механизме управляемых блокировок:

С версии платформы 8.1 у нас появился режим управления блокировкой данных «управляемый»

К механизму блокировок СУБД добавляется механизм блокировок на сервере 1С. Блокировки мы можем ставить руками в коде с помощью объекта «БлокировкаДанных», также управляемая блокировка автоматически ставится при любой записи и при чтении данных в объектной технике, т.е. не запросом, а при получении каких-то данных в коде. Подробнее о механизме блокировок 1С можно я рассказывал здесь и здесь.

Теперь давайте разберем события ТЖ подробнее. EXCP:

События EXCP были следующего вида:

Ещё одно исключение для примера:

Я немного упростил лог. По этим строчкам видно, что возникали таймауты и дедлоки под пользователем АдминистраторWMS, в контексте отложенного проведения документов.

В нашей статье разберем взаимоблокировку. Смотрим событие TDEADLOCK:

Давайте разбирать этот жуткий текст. Взаимоблокировка, тот же пользователь АдминистраторWMS, далее идет информация о 2х блокировках, на которых и возник конфликт.

1. 2896 2894 Seq31427.DIMS Exclusive Fld31428=79:a0b0000c6eb6752411db283f6c576d63
   • 2896 – соединение, ожидающее блокировку
   • 2894 – соединение, установившее блокировку
   • SeqDIMS заблокированный ресурс. Имя таблицы начинается на Seq, значит это последовательность. Обработкой «Структура БД» по имени таблицы мы можем найти, какая именно последовательность.
   • Exclusive – это тип блокировки «исключительная», такая ставится при записи
   • Fld31428=79:a0b0000c6eb6752411db283f6c576d Сама блокировка на поле Fld31428. Это поле тоже можно «расшифровать в обработке «Структура БД»
2. 2894 2896 AccRg14235.DIMS Exclusive
   • Те же 2 сеанса, только наоборот. 2896 установил блокировку, 2894 – ожидает
   • AccRgDIMS Exclusive. Эксклюзивная блокировка на таблице AccRg14235. Это РБ Хозрасчетный.

Итак, типичный случай взаимоблокировки «захват ресурсов в разном порядке». 1 сеанс заблокировал последовательность и ждет Хозрасчетный, второй сеанс заблокировал Хозрасчетный и ждет последовательность.

Теперь по номерам сеансов и датам событий мы найдем события TLOCK и посмотрим более детально, что происходило в каждом из этих сеансов.

Это 2 события TLOCK, на которых были ожидания блокировок. Мы видим наши номера сеансов connectID, а также WaitConnections – номера сеансов, которых ожидали. И контексты. В одном случае идет запись данных при проведении, а в другом – удаление записанных движений в начале проведения.

Проблему обнаружили. Теперь подумаем, что можно сделать для её решения и почему вообще она возникла.

Во-первых, и сеансы-виновники и сеансы-жертвы – это обмен с системой WMS. Таким образом получается, что обмен с WMS может проходить одновременно в несколько сеансов. Если по бизнес-логике в этом нет необходимости, можно исключить возможность параллельных обменов.

Во-вторых, блокировка при записи РБ Хозрасчетный. Даже если запись идет по одному набору измерений, ожиданий быть не должно, если включен режим разделения итогов.

Как видим, режим разделения итогов выключен. Необходимо включить.

И в-третьих, блокировка на последовательности при записи возможна только на одинаковом наборе измерений последовательности и если граница смещается при проведении. Находим нашу последовательность и смотрим свойства:

У данной последовательности 1 измерение «Организация». Соответственно, все документы, которые участвуют в последовательности, пытаются двигать её границу при проведении и ждут друг друга. Типовые последовательности двигают границу только назад, а вперед граница двигается специально обученной обработкой. В нашем случае необходимо анализировать логику работы и отказаться от оперативного перемещения границы, если есть такая возможность.

Остальные проблемы, а также настройку и работу с ТЖ смотрите на наших вебинарах.

Спасибо за внимание ��

Смотрите также:

Сегодня речь пойдет о блокировках данных в 1С. В видео использованы материалы статей: Материалы в рубрике Эксперт 1С Все видео из цикла «Записки эксперта»: Технологический журнал 1С (Записки эксперта…

Небольшая зарисовка на тему, какие были бы сливные трубы, если бы их делали 1С-ники.

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

Ошибка в 1с не удалось заблокировать таблицу. Тормоза на файловой базе — как избежать (из недавнего опыта)

Как часто приходиться видеть это сообщение? Думаю, каждый кто имеет продолжительный опыт работы с 1С, хоть один раз да сталкивался с такой ошибкой. Из-за чего же программа выдает такую вот ошибку «Конфликт блокировок при выполнении транзакции: Не удалось заблокировать таблицу»?

Ну чаще всего это происходит из за того, что кто-то из пользователей уже проводит какую-то операцию, которая заблокировала данную таблицу. Чтобы решить данную проблемы всем пользователям достаточно выйти из программы. Но бывает и так что пользователь вышел из программы, а процесс программы из памяти не выгрузился. Не паникуйте! Если все пользователи вышли из программы, а сообщение все равно выходит, нужно открыть меню Сервис — >Активные пользователи.

И посмотреть, кто кроме вас в данный момент работает с программой. Если все пользователи вышли, а вы все таки видите, что кроме вас есть еще кто-то, не пугайтесь. Так бывает. Завис процесс. Перезагрузите компьютер пользователя который находиться в активных.

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

В данном случае и почти всегда, если приведенные выше рецепты не помогли, помогает утилита chdbfl.exe. Находиться она в папке с исполняемым файлом 1С. Путь до файла будет приблизительно такой «C:\Program Files\1Cv82\номер_версии_платформы\bin\chdbfl.exe». Обратите внимание что данная утилита от одной версии платформы, может не подойти к другой.

Поэтому открыть нужно папку, именно с номером текущей платформы, на которой вы работаете.

Как посмотреть номер платформы? Очень просто. Заходим в меню Сервис -> О программе. И дальше на картинке показано, где смотреть номер платформы.

Ставим галочку «исправлять обнаруженные ошибки». И нажимаем кнопку выполнить. Данная утилита исправляет 90% всех происходящих ошибок. Настоятельно рекомендую перед применением данной утилиты сделать резервную копию базы данных, ну а если ошибка происходит как раз в момент выгрузки, то скопируйте целиком папку с информационной базой данных.

Симптомы пациента и анамнез:

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

Основные признаки работы блокировок:

• быстрая работа пользователя с базой по сети в монопольном режиме и крайне медленная — при одновременной работе нескольких пользователей
• быстрая работа пользователя с локальной базой на сервере и медленная — по сети
• обращения к файловой системе чуть менее 10 мбайт/сек

Итак, мне досталась задача — сделать так, чтобы в 1С могли одновременно работать целых три пользователя! Смешно, не так ли?

Все шуточки я забыл, когда увидел, с чем предстоит иметь дело: «сервер» в лице обычного офисного компьютера и два ноутбука.

Счастье было бы неполным, если бы не замечательные операционные системы — на компьютере и на одном ноутбуке Windows 7, на другом — Windows 8.

При попытке одновременно провести документы на ноутбуках один тупил около минуты, а второй вылетел из 1С с текстом ошибки «не удалось заблокировать таблицу. «.

Запуск 1С на ноутбуке — это отдельное шоу, длившееся порядка 3 минут!

На многих ресурсах сталкивался с советом перейти на работу в терминальном доступе. К сожалению, Windows 7 не позволяет штатными средствами превратиться в сервер терминалов — максимум одно активное подключение. При этом остальные сеансы не прекращаются, можно переподключиться под другим пользователем — «выкинув» при этом предыдущего пользователя, но не завершив его сеанс. Поэтому следует перенести 1С на серверную ОС, где таких ограничений нет. Клиент на свой страх и риск решил проблему вместо этого с помощью сторонней утилиты Windows7_SP1_RDPhack.

Но на этом приключения не закончились. Даже в терминальном подключении остались значительные тормоза. Вновь меня выручили всемогущие поисковики. Ниже даны советы по ускорению файловой 1С, которым я последовал:

1. Отключить использование протокола сети IPv6 , настроить адресацию на «старом» IPv4.

2. Добавить процессы 1С в исключения брандмауэра Windows, а также в исключения антивируса, либо отключить их вовсе (более рискованно, но простой тест показал увеличение скорости перепроведения документов при отключенном антивирусе Avast в разы !)

3. Запустить индексацию полнотекстового поиска в 1С либо выключить его вовсе

4. Запустить Тестирование и исправление базы, проверку утилитой ChDbfl

5. Запустить в конфигурации пункт Проверка конфигурации (если конфигурация не типовая, это может быть полезным). По результатам проверки конфигурации она волшебным образом уменьшилась в размерах почти на треть. Что уж и как до меня обновляли приходящие программисты — особо не вникал, но факт налицо.

6. Отключить ненужные функциональные опции.

7. Настроить права пользователям. (Этот и предыдущий советы показались глупостью, до тех пор, пока я не понаблюдал за отрисовкой управляемых форм при открытии списка документов. Чем меньше лишнего в управляемом интерфейсе — тем, как правило, быстрее он работает)

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

9. Указать «Скорость соединения — низкая» в настройках списка баз (это особого результата не дало, разве что отключились картинки у подсистем:))

После выполнения всех этих шагов файловая база 1С заработала на порядок шустрее. Запускаться стала максимум секунд за 10, а скорость перепроведения документов увеличилась в среднем в 12 раз.

Возможно, эта небольшая статья пригодится и вам, если вдруг понадобится ускорить файловую базу 1С.

P.S: А запустить файловую 1С, используя сетевой доступ к общей папке — все же нереально, т.к. даше самый шустрый твердотельный диск, оперативная память и процессор уткнутся в сетевые блокировки, и работа более одного пользователя будет фактически невозможна. Речь идет конкретно о конфигурации УТ 11.1. Самописные небольшие конфигурации вполне могут работать весьма быстро даже в файловом варианте.

Дополнения из комментариев к публикации:

Дефрагментация диска с файловой базой

Свертка базы (может оказаться полезной, если база большого объема, например, за несколько лет). У клиента база была достаточно молодая, поэтому свертка была нецелесообразна.

Модернизация аппаратной части — более быстрый винчестер, новый свитч, процессор, и т.д.

Установить на веб-сервер , доступ с помощью тонкого клиента. Тут мнения разделились. Кто-то говорит, в разы быстрее, кто-то — что ускорения не отмечено.

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

Большое количество выполняемых операций

Первым делом при поиске причин следует уточнить, сколько же одновременно работающих пользователей находится в той информационной базе, в которой выдается подобная ошибка. Как мы знаем, максимальное их количество может быть довольно большим. Это и тысяча, и пять тысяч.

Механизм блокировок и транзакций описан в руководстве разработчика. Их используют при обращении нескольких сеансов к одним и тем же данным одновременно. Логично, что одни и те же данные не могут изменяться разными пользователями в один и тот же момент.

Так же следует проверить, не запущено ли у кого-то из пользователей обработки по массовому изменению данных. Это может быть как , закрытие месяца и тому подобное. В таком случае после окончания работы обработки ошибка пропадет сама по себе.

Регламентные задания

Не редки случаи, когда причина ошибки кроется в , которое обрабатывает большое количеств данных. Рекомендуется подобные вещи делать ночью. Задайте расписание выполнение таких регламентных заданий во внерабочее время.

Таким образом, и пользователи будут работать в стабильной системе, и сами регламентные задания будут завершаться успешно, так как снизится вероятность возникновения конфликтов с пользовательскими сеансами.

«Зависшие сеансы»

Проблема «зависших сеансов» пользователей знакома практически каждому, кто сталкивался с обслуживанием 1С. Пользователь мог уже давно выйти из программы, или закрыть какой-либо документ, но его сеанс по-прежнему остается в системе. Проблема чаще всего единичная и достаточно завершить подобный сеанс через консоль администратора. Такие же проблемы могут возникнуть и с фоновыми заданиями.

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

Ошибки при написании конфигурации

Все типовые конфигурации разработаны квалифицированными специалистами и экспертами. Каждая система тщательно тестируется и оптимизируется для более быстрой и корректной работы в ней.

В связи с этим причина ошибки может крыться в неоптимальном коде, написанном сторонним разработчиком. Это может быть «тяжелый» запрос, который будет блокировать данные на длительный промежуток времени. Так же нередки случаи построения алгоритмов с низкой производительностью и нарушением логики.

Большая вероятность, что конфликт блокировки возник именно из-за ошибок разработчика, если он возник после обновления программы. Для проверки можно просто «откатить» доработки, либо произвести рефакторинг кода.

Стоит 8.1 комплект на 5 пользователей.
Юзаем типовую бухгалтерию.
Работают в основном через терминал, иногда и без него.
Вариант базы данных — файловый
Ошибки замечены у тех, кто в терминале

как-то так. Порылся в нете, Яндексе — вообщем как-то неконкретно всё.
Основные найденные рекомендации:
1) Выгрузить/Загрузить базу — в смысле новую состряпать из конфигуратора
2) запустить \Prоgram Files\1cv81\bin\chdbfl.exe — проверка физической целостности базы
3) Провести Тестирование и исправление информационной базы
4) обновиться на последний релиз 8.1

Кто-нибудь что-нибудь поконкретнее знает?

Все что надо, вам уже предложили, сначала это пробовать. Физических ошибок на носителе то нет?
Поконкретнее врят ли кто скажет.

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

P.S. А файловые БД в многопользовательском режиме это извращение.

Хотя хрен его знает как у 1С-в сделана БД, вполне может быть, что где то в БД ля запала и всяческие репайры помогут.

Да сдается мне, восьмерина как платформа — сырость та еще. Где-то писали, что ПЕРИОДИЧЕСКИ тестирование с исправлением приходиться делать

маловероятно. Для восьмерки новый сервак куплен аж с лицензионной виндой

Суть в том, что один блокирует таблицу, остальные ждут до тайм-аута.
Почему не успевают, это большой вопрос. Физический носитель поглядеть, может тупит. Системный журнал, MHDD. И все те действия, что написаны в первом посте обязательно.

P.S. Новое не значит что 100% рабочее.

Все что надо, вам уже предложили, сначала это пробовать

так то да, это до вечера надо ждать.
Была маленькая надежда что-нибудь новое услышать

Не рассказывайте чудес. Там бед хватает, но это не они.

где чудеса-то? Я не понял, кто-то собрался утверждать, что 8.1 крутая безупречная платформа?

писали, что ПЕРИОДИЧЕСКИ тестирование с исправлением приходиться делать

у нас похоже такой случай и есть.
Опрос пользователей поодиночке (чтобы не врали дружно) показал, что эта ситуация встречается вроде бы ТОЛЬКО у пользователей, работающих в терминале. А те кто ходят не через терминал, на котором
Windows Server 2003 R2 Standart 64, либо не помнят такой ситуации, либо её просто не возникало у них.
Причем двое особо наблюдательных отметили, что 1.5-2 месяца назад это явление наблюдалось НАМНОГО реже

Born Killer , Антивирь какой-нить стоит на серваке? Если да, попробуй отключить или базу в исключения добавить

Антивирь какой-нить стоит на серваке?

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

нет там похоже антивируса.

Я не понял, кто-то собрался утверждать, что 8.1 крутая безупречная платформа?
да ну нах. 7.7 то лажа местами до сих пор, а про 8-ку впору слагать легенды о её глючности

Сколько база размером и какое количество пользователей?

Слагайте. Приведите конкретный пример.
Сколько база размером и какое количество пользователей?

ночью сделал тестир и исправл. До этого 1cv8.1CD был 2Гб, сейчас 1.5Гб стал.
Пользователей 5 штук, как и собсвенно лицензия.
Насчет легенд о глючности, был один случай. Вот если взять 7.7 и просто через Тотал скопировать 1 базу в другое место — копия без проблем.
Однажды попробовал тоже самое сделать с восьмерошной базой, скопировал каталог базы в другое место,
прописал, открыл обе базы одновременно, одна предполагалась для извращений.
В копии пометил на удаление несколько документов, переключился в окно с реальной базой не поверил глазам: те же самые документы пометились на удаление и там

Ясень пень, у 1С на всё есть ответ: делайте ежедневную копию базы данных.
Да только это ху е вый ответ

Born Killer ,

Миф!
Вот так рождаются легенды.

привет, подруга. Вот тебя занесло то

А потом замироточили иконки на рабочем столе

Миф!
Вот так рождаются легенды.

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

не помню какая платформа тогда стояла.

попробуйте сделать также. Может и у вас чо получится

Вот так рождаются легенды.

скажу больше: когда я в копии вручную у парочки документов снял пометку на удаление,
в реальное базе произошло тоже самое. Мне тогда не до того было, чтобы как-то документировать эту сенсацию.
Поэтому я просто вернул все как было, и больше так не делал

устраняю зияющие дыры в познаниях компьютера.
правда, по-моему, я безнадежна.

конкретно эта тема вообще не для тебя, родная (с)
а вообще, всё поддается осмыслению
заведи друга компьютерщика, как вариант)))

В копии пометил на удаление несколько документов, переключился в окно с реальной базой не поверил глазам: те же самые документы пометились на удаление и там shok.gif

Вот уж никогда файловую базу то ни копировал 8-шную
Это была отнюдь не сенсация.

Вы блин можете не верить, но это БЫЛО.

Дело в том, что с 8-кой несколько лет работал очень плотно. Как только их не копировали. Так что поверить не могу
Но могу предположить, что когда чел переутомился — возможно многое. По себе знаю.

Не парься, файловую базу можно спокойно копировать и поднимать в любом другом мести. Никаких глюков быть не должно.

Есть прредположение-по запарке прописал одну и ту же базу 2 раза

8-ка предлагает заменить

нее. 7.7 при попытке это сделать тупо молчит и базу в список не добавляет (просто никак не реагирует)
8-ка предлагает заменить

Мож просто мышой промазал и запустил одну и ту же. Чудес ведь не бывает

Мож просто мышой промазал и запустил одну и ту же.

дома попробую что-нибудь подобное смоделировать. Потом отпишусь.
Обычно перед всяким опасным действием я в 1С (7.7. или 8-ке) жму на знак вопроса (там путь к базе показан).

Тут народ так дружно мою легенду на смех поднял, что я засомневался.
Хотя глюков в восьмерке больше чем в семерке.

О, вот стопудовый глюк, это видел не только я.
Вообщем издевались над одной 8-й базой у клиента, когда я еще во франчике работал.
Один день один чел, другой — второй, на третий я пошел. Спросил у них — резеврную копию перед подвигами делали? В ответ — ржут, как лошади, забили короче, только они базу брали на той машины

— ржут, как лошади, забили короче, только они базу брали локально,
а мне выпал случай со сети её ебошить. Резервную копию по примеру предыдущих таварисчей решил не делать,
молодой был и глупый — понтов много.
Вообщем внес изменения в конфу, сохраняю конфу, в момент сохранения конфы какая-то авария случилась, и база упала, вечером. Шок. С утра пошли 3 спеца, включая меня туда.
Авария заключалась в том, что у базы оторвало номер релиза, т.е. в конфигурации при нажатии вопросик там было пусто, и название самой конфы отсутствовало. и при в ходе в базу тоже не видно ни хрена было, интерфейс в т.ч. слетел, в журналы документов было не зайти.
Решили проблему обновив убитую базу относительно свежим файлом конфигурации, всё получилось.
Все возродилось.
Это пример реальной легенды. 3 человека не должны глючить одновременно

в момент сохранения конфы какая-то авария случилась, и база упала

Ну если это был глюк железа, тогда ничего удивительного.
А вот если бы ты нашел баг , который стабильно появляется после выполнения определенных действий, тогда другой разговор.

Ну если это был глюк железа, тогда ничего удивительного

хз, что было. железо, сетка или платформа — сейчас уже не так важно.
Мне кажется, софтина не должна так феерически себя вести
Это тоже самое, что выпустить Висту, и признать, что это говно. Как то быстро они с 8.0 на 8.1 перескочили
П.С. смысл слова баг мне понятен, спасибо за заботу)))

Скажем, если при накатывании сервис-паков или чего-то важного на ту же Висту произойдёт подобный «глюк», то вполне вероятно, что система потом, если и загрузится, то работать будет крайне нестабильно.
Или, скажем, в момент принятия инсулина произойдёт землятресение, то диабетик может отдать концы, т.к. шприц при тряске закатился под диван.

Born Killer, Антивирь какой-нить стоит на серваке? Если да, попробуй отключить или базу в исключения добавить

Как антивирус может повлиять на блокировки таблицы?? база 8.х — это один файл.

В копии пометил на удаление несколько документов, переключился в окно с реальной базой не поверил глазам: те же самые документы пометились на удаление и там shok.gif
Вообщем эта сраная ботва мне не понравилась, с тех пор копию базы делаю только через Выгрузить/Загрузить.
Как вам сударь, такая печальная легенда?
А если бы я увлекся и посерьезней вещи натворил в копии (например удалил бы помеченные на удаление документы), и каким то неясным образом, те же действия произвелись в основном базе?

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

периодически полезли косяки при проведении/записи документов с ошибкой вида
«Конфликт блокировок при выполнении транзакции: Не удалось заблокировать таблицу «_DOCUMENT158»

Так первым делом нужно определить какому документу метаданных соответствует таблица «_DOCUMENT158». Для этого есть метод глобального контекста «ПолучитьСтруктуруХраненияБазыДанных». Так ты поймешь хотя бы точно, какой документ «глючит».

Потом нужно понять, не менял ли кто в нем модуль проведения и настучать по башке, если меняли через одно место. Вероятнее всего явным образом записывается наборы записей регистров через метод Записать вместо того чтобы предоставить платформе это сделать корректно. И напутана их последовательность..
А дедлоков не возникает?

А вообще 5 человек не стоит держать в файловом режиме. Субд можно взять бесплатную, докупить только ключ для сервера кластера и все. Или это конторе дорого?
Я вот не помню, технологический журнал можно снимать в файловом режиме или нет.

То есть транзакция не проходит даже когда работает один пользователь?? Тогда вероятно проблема не в кривом коде при записи движений. Потому как в однопользовательском режиме блокировок быть не может. Запись ведь последовательно производится.

Тогда похоже проблема именно в нарушениях в структуре самой базы..
Лучше сначала выполнить Тестирование и исправление базы с включенным флагом «Реструктуризация таблиц информационной базы».
Выгрузка в dt с последующей загрузкой тоже имеет смысл.
chdbfl.exe в этом случае вряд ли поможет. хотя конечно пробовать стоит, если остальное не поможет.

Гы — тока щас посмотрел на дату постов в ветке http://odines.ru/thread1386.html Да и разработка типовых в новом управляемом режиме не за горами.
А уж разница между 8.2 и 8.1 намного больше чем между 8.1 и 7.7 особенно для разработчиков, мозги приходится капитально перестраивать для разработки под «управляемый» режим работы

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

Конфликт блокировок в 1С 8.3 и его значение

Для большинства пользователей сообщение о конфликте блокировок 1С означает лишь ошибку, мешающую им выполнять свою работу. Они хотят поскорее избавиться от этой проблемы и осаждают IT-отдел жалобами на то, что «1С не работает».

Но для системных администраторов и разработчиков такое сообщение говорит о возможном наличии проблем в структуре конфигурации. Перед тем как пытаться угодить пользователям и убрать блокировки, необходимо проанализировать ситуацию и понять причину возникновения сообщения об ошибке.

Причины возникновения ошибок блокировки в 1С

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

Если не брать идеальные варианты, то конфликты блокировок 1С встречаются по следующим причинам:

Одновременная работа пользователей с большим объемом данных. Эта первопричина продиктована внутренними механизмами 1С. Они предполагают запрет изменения данных, вовлеченных в транзакцию, запущенную от имени другого пользователя;

Ошибки и недочеты в конфигурации. В структуре типовых решений от компании «1С» учтены рекомендации по максимизации производительности. Но сторонние разработчики не всегда придерживаются высоких стандартов, и в их коде часто можно встретить следующие недочеты:

• Неоптимальные запросы;
• Запрос остатков в начале действий;
• Непонимание предназначения объектов конфигурации и их неправильное применение;
• Избыточность заложенных в системе или дополнительно разработанных блокировок.

Как исправить конфликт блокировок в 1С 8.3

Системное сообщение «конфликт блокировки при выполнении транзакции 1С 8.3» не характеризует конфигурацию в качестве неверно спроектированной. Но если подобные сигналы игнорировать, то существует вероятность в самый ответственный момент, например, при сдаче квартальной или годовой отчетности получить большие проблемы. В лучшем случае – тормозящую систему и недовольных пользователей. В худшем – неправильные данные на выходе, что может повлечь за собой штрафные санкции от контролирующих органов.

Решением проблемы конфликта блокировок в 1С 8.3 может стать перевод конфигурации на управляемый (ручной) режим управления блокировками. Реализованный в версии 8.1, механизм в руках грамотных специалистов решает проблему конфликта блокировок при транзакции в 1С.

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

Быстрое решение конфликта блокировок 1С

В работе администратора или разработчика может произойти ситуация, когда нет времени на проверку ошибки и поиск первопричин проблемы. Например, необходимо сдать отчет или подать данные к определенному времени, а ошибки блокировок 1С препятствуют этому.

Для быстрого решения проблемы существуют два пути:

• Найти и завершить сеанс, заблокировавший необходимые данные. В небольших компаниях, где количество пользователей 1С не превышает пары десятков человек, это оптимальный вариант решения;
• Если вы контролируете систему, в которой работают сотни сотрудников, поиск нужного сеанса без специализированного программного обеспечения может затянуться надолго. В этом случае намного эффективнее будет перезагрузить сервер.

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

Конфликт блокировок при выполнении транзакции 1с 8.3 как исправить?

Для расследования конфликтов на управляемых блокировках, во-первых, необходимо настроить технологический журнал на сбор событий TLOCK, TTIMEOUT, TDEADLOCK, при необходимости дополнительно установив отбор по имени базы в свойстве p:processName

Нестандартные способы

До этого были проделаны все стандартные операции по исправлению данной ошибки, и если до этого момента ошибка не устранена, значит придется заняться «творчеством». Ещё этот процесс называют «танцами с бубнами» или «шаманством»… Поэтому, если до этого вы не «танцевали», то ошибка формата потока 1С Предприятие 8.3 может вам составить отличную пару. Итак, продолжим:

• Пробуйте загрузить файл *.dt в новой базе данных, созданной на другом компьютере. Этим вы исключите вероятность некорректно работающего железа или программ компьютера, где находится база.
• Удалите (именно УДАЛИТЕ через Установку и удаление программ) платформу 1С и установите заново, желательно новейшую версию. Исключаем некорректно работающие исполняемые файлы платформы, которые могли быть подпорчены вирусами или «посыпавшимися» секторами жесткого диска или другими способами.
• Обновите конфигурацию на следующий релиз или загрузите текущую конфигурацию из файла *.cf с полным замещением объектов.
• Отключите брандмауэр и антивирусы. Существует вероятность, что исполняемый файл был замечен в подозрительной активности антивирусом и помещен в карантин или остался под жестким контролем с блокировкой «опасных» действий. В любом случае — исключаем вариант карантина антивирусов.
• Удалите временные файлы на компьютере. Они находятся в нескольких местах:

1. В профиле пользователя, для поиска введите %Temp% в адресной строке проводника.
2. В папке C:\Windows\Temp
3. Иногда на диске C:\Temp

Ещё один способ был однажды применен, когда ничто не помогало — создали полный начальный образ базы данных и потом отвязали его от РИБ, сделав независимым. Получили ту же базу, пропустив начальную через механизмы РИБ.

Не получилось исправить ошибку в 1с?

Если у Вас не получилось исправить какую-нибудь ошибку в 1с не стоит отчаиваться, поднимите трубку и позвоните нам! Наши специалисты всегда готовы Вам помочь в решении любых вопросов связанных с 1с, в том числе и с ошибками возникающими при работе системы.

18 сентября 2013 в 15:24

1С, восстановление конфигурации информационной базы с использованием MS SQL

В свое время столкнулся с проблемой: при обновлении конфигурации из хранилища, произошел сбой, и закрылась 1С.

Как выяснилось позднее – произошло разрушение хранилища конфигурации и при обновлении конфигурации из хранилища слетела и конфигурация БД. Подобная ошибка возникала прежде при динамическом обновлении ИБ.

Т.к. данная проблема возникала не однократно решил поделится вариантом лечения.

При следующем запуске конфигуратора вышла ошибка: «Внимание. При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» при утвердительном ответе получаем сообщение: «Обнаружена незавершенная операция сохранения конфигурации

Для продолжения работы необходимо завершить операцию» после этого приложение закрывается.

При разборе данной проблемы было найдено несколько вариантов решения проблемы, каждое решение работает в разных случаях.

Вариант 1 (при наличии бэкапа SQL c копией с идентичной конфигурацией):

Разворачивается копия ИБ, и выполняется запрос следующей конструкции: USE
GO
DELETE FROM ..
GO
INSERT INTO .. SELECT * FROM ..
GO

При этом пере заливается таблица в которой хранится конфигурация ИБ. Желательно после данной операции выполнить тестирование и исправление ИБ.

Вариант 2 (при отсутствии бэкапа):

К данному варианту обратились как к последней соломинке. Т.к. конфигурация была в стадии разработки и про бэкап немного позабыли понадеясь на хранилище.
В базе удаляются две записи из таблицы «Config» по значению в столбце «FileName» — dbStruFinal и commit

Выполняется следующий запрос: USE
GO
DELETE FROM .
WHERE FileName = «dbStruFinal»
GO
DELETE FROM .
WHERE FileName = «commit»
GO

Как ни странно база оживает.

Теги:
1с предприятие 8.2, SQL, восстановление конфигурации

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит

В статье показаны способы восстановления базы 1С с помощью встроенных в программу инструментов или сторонних приложений
. Как создать и восстановить резервную копию базы данных.
Для большинства пользователей продуктов компании 1С , повреждение или утеря базы «1С: Предприятие» есть тем, о чём даже боятся говорить. Для них, задача по восстановлению базы данных кажется просто нереальной, а её утеря страшной трагедией.

На самом деле, продукты компании 1С являются таким же программным обеспечением, как и любое другое. Информация, которую пользователи вносят в свои базы данных сохраняется в файлах, из которых можно создавать резервные копии или восстанавливать в случае повреждения или удаления. Часто для этого достаточно встроенных в «1С: Предприятие»
инструментов, но и о стороннем программном обеспечении также забывать не стоит.

По умолчанию, каталогом информационной базы, в котором кроме файла самой базы 1С сохраняются все файлы, которые имеют к ней отношение, является папка в Документах пользователя: C:\Users\Имя Пользователя\Documents\InfoBase

В этой папке хранятся все файлы, которые имеют отношение к данной базе данных.

К таким файлам относятся:

• *.1CD
  – файл самой базы данных, который по умолчанию имеет название 1Cv8.1CD. Данный файл включает в себя все данные, которые внесены в базу данных, а также их конфигурацию;
• *.cf, *.cfu (*.cfl), *.dt, *.epf (*.erf)
  – конфигурационные файлы базы данных;
• *.log, *.lgf, *.lgp, *.elf
  – лог файлы;
• *.cdn
  – файл блокировки базы данных 1С;
• *.efd
  – архивный файл 1С;
• *.mft
  – вспомогательный файл конфигурации шаблона;
• *.st
  – файл шаблонов текстов
• *.mxl
  – файл печатных форм базы данных 1С;
• *.grs
  – файл графических схем базы данных 1С;
• *.geo
  – файл географических схем базы данных 1С.

В данной транзакции уже происходили ошибки

Причина появления данной ошибки — вызов исключительной ситуации в транзакции. Попытка создает неявную транзакцию, тем самым исключение откатывает транзакцию полностью.

Внутри транзакции вызывается исключительная ситуация, что откатывает всю транзакцию и некорректно отрабатывает. Например:

1. НачатьТранзакцию();
2. ….
3. ….
4. Попытка
5. ….
6. Исключение // если тут будет вызвано исключение, то Вы увидите ошибку «В данной транзакции уже происходили ошибки»
7. ….
8. КонецПопытки;
9. ….
10. КонецТранзакцию();

Во избежание таких ситуаций нужно избегать использования попытки внутри транзакции.

Если у Вас появляется данная ошибка, но Вы не в курсе, что такое транзакция и как программировать в 1С 8.3, Вам лучше обратиться за помощью к опытному программисту 1С.

Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):

Есть ли смысл исправлять ошибки транзакции, которые уже происходили

При работе с 1С 8.3 не стоит оставлять подобные вещи без внимания. Прежде всего, другой пользователь также может столкнуться с ней, но не поймет причин её возникновения. Если не выполнить отладку системы, то в дальнейшем могут возникнуть дополнительные проблемы. Так как оповещение «В данной транзакции уже происходили ошибки» появляется при первом обращении, то в журнале регистрации данная строка обязательно зафиксируется, но, опять же, без подробного пояснения. Хоть ошибка и располагается на нижнем уровне кода, она нарушит необходимую иерархию. Это приведет к сбою других функций и только еще больше запутает администратора.

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

Способы устранения ошибки

Если вы стали свидетелем возникновения сообщения «Ошибка загрузки метаданных в 1С на Windows 7», панику отбросьте в сторону, сосредоточьтесь и начните разбираться с тем, как всё-таки решить возникшую проблему. Поверьте, если следовать рекомендациям, эта проблема не покажется для вас такой уж страшной и неимоверно сложной.

Конечно, вы должны понять, что привести к ошибке метаданных в 1С 7.7 может не одно только повреждение, а сразу несколько. Только в связи с тем, что первоначально программа загружает md.файл, она, выявляя его повреждение, сигнализирует об этом сообщением «Ошибка метаданных 1С». Узнать сразу об остальных неисправностях компонентов баз вы просто не можете, поскольку программа просто вас об этом не уведомляет.

К сожалению, спровоцировать такую ужасную для вас проблему, могли вы даже собственноручно. Это часто случается, когда возникает желание переписать md.файл, воспользовавшись копией. Это катастрофическая ошибка для программы, поэтому совсем неудивительно, что она начинает «мстить» бухгалтерам за неумелое обращение с ней. Желая переписать информацию, недопустимо делать копию.

Алгоритм действий

Чтобы не навредить ещё сильнее программе, важно неукоснительно следовать рекомендациям опытных пользователей. Если обнаружена уже повреждённая информационная база, не торопитесь предпринимать какие-либо действия до тех пор, пока не сделаете посекторную копию

Если выполнить такие рекомендации, впоследствии удастся базу легко восстановить. К сожалению, те, кто игнорирует эти советы, могут лишиться возможности устранить системный сбой. Итак, если в 1С Предприятие возникла ошибка загрузки метаданных, первым делом проверьте, а видит ли сама программа путь к информационной базе.

Если даже видит, не спешите переходить к следующим шагам, проверьте правильность указанного пути. Иногда при системном сбое путь становится некорректным, безусловно, воспользоваться информационной базой программа не может, по этой причине она не будет корректно загружаться. К сожалению, если путь правильный, значит, проблема всё-таки посерьёзнее, но и с ней можно разобраться.

Начнём искать причины проблемы, если ПО видит этот файл, но не может его прочитать. Предлагаем вам открыть проводник Windows, после чего попытаться создать точную копию файла конфигурации, размещая его на другом дисковом пространстве.

Если даже при таких действиях возникает сообщение об ошибке, сообщающей, что не удаётся прочитать файл, значит, высока вероятность того, что ваш диск, на котором сохранена база, просто повреждён. Иногда такое случается, когда на съёмном диске устанавливается защита, ограничивающая права на чтение.

К сожалению, достаточно часто бухгалтера сталкиваются с тем, что файл можно прочитать, но он оказывается повреждённым по причине вирусной атаки, некорректного выключения и прочего

Итак, прежде чем приступить к дальнейшим действиям, очень важно сделать резервную копию, которую разместить на другом дисковом пространстве

Хорошо, если бухгалтера периодически создают резервную копию, тогда достаточно распаковать эту копию и заменить повреждённый файл этой копией. Если же такого «спасительного» архива просто нет, воспользуйтесь «дружеской» помощью утилиты GComp. Эта утилита помогает распаковать файл конфигурации, а затем точно также его успешно упаковать, восстановив работоспособность программы.

Также рекомендуем просмотреть название фала, воспользовавшись любым HEX-редактором. Если вы обнаружите, что ничего общего с Compound он не имеет, значит, кто-то его с «огромным аппетитом скушал». В большинстве случаев после вирусного вмешательства что-то сделать с таким файлом уже невозможно.

Если в вашей программе была установлена конфигурация стандартная, тогда поищите такую же на просторах интернета, после завершения успешных поисков, просто её замените. Конечно, если файл содержал крайне важную информацию, лучше доверить все эти манипуляции профессионалам, которые в большинстве случаев смогут вернуть вам потерянное.

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

Исправление ошибки SDBL

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

Перезагрузка сервера 1С и SQL-сервера

Самый простой способ, при условии, что на текущий момент в базе никто не работает.

Зайдите на сервер и выключите следующие службы:

• «Агент сервера 1С»,
• «SQL Server»,
• «Агент SQL Сервера».

А затем запустите их обратно.

Очистка кэша на сервере и клиента, где проявилась ошибка

В некоторых случаях исправить ошибку SDBL можно с помощью очистки кэша сервера 1С.

Как правило кэш расположен по адресу:

• «%userprofile%\Local Settings\Application Data\1C\1Cv8» и «%userprofile%\Application Data\1C\1Cv8» для Windows XP,
• «%userprofile%\AppData\Roaming\1C\1Cv8» и «%userprofile%\AppData\Local\1C\1Cv8» для Windows 7 и выше.

Перейдите в данный каталог и удалить все папки с генерированными именами вида « dg7c8re4-b89r…». При удалении будьте внимательны — в этой директории может присутствовать индекс полнотекстового поиска 1С, а также журналы регистрации, их удалять не нужно.

Перезаливка базы из DT-файла

Иногда помогает, казалось бы, парадоксальный способ — выгрузка базы данных в файл формата DT, а затем загрузка его обратно.

Войдите в режим «Конфигуратор», выберите пункт меню «Администрирование» > «Выгрузить информационную базу» и выберите каталог для сохранения файла.

Затем через аналогично через меню «Администрирование» > «Загрузить информационную базу» загрузите его обратно.

Тестирование и исправление Информационной базы

Для тестирование и исправление Информационной базы: войдите в «Конфигуратор», выберите пункт меню «Администрирование» > «Тестирование и исправление».

В случаях, когда невозможно запустить конфигуратор, воспользуйтесь утилитой chdbfl.exe. Это упрощенная программа-аналог тестирования базы, функции, которая запускается в режиме конфигуратора. Расположена она в папке «bin» установленной технологической платформы, например, C:\Program Files (x86)\1cv8\8.3…\bin\chdbfl.exe.

Пользоваться ей просто — указываете путь к файлу базы данных и ставите опцию, нужно ли сразу исправлять обнаруженные ошибки. Если нет — утилита только продиагностирует ИБ.

Обновление платформы до новой версии

В данном случае всё достаточно просто. Скачивает с сайта поддержки 1С дистрибутив свежей версии платформы, распаковываем и запускаем инсталятор setup.exe.

Очистка таблиц базы данных

В крайнем случае можно попробовать удалить таблицы БД, связанные с ошибкой — «dbo._ConfigChngR» и «dbo._ConfigChngR_ExtProps».

Производится это через менеджер SQL-скриптом вида: use имя_базы_данных delete from dbo ._ ConfigChngR delete from dbo ._ ConfigChngR _ ExtProps

Есть ли смысл исправлять ошибки транзакции, которые уже происходили

При работе с 1С 8.3 не стоит оставлять подобные вещи без внимания. Прежде всего, другой пользователь также может столкнуться с ней, но не поймет причин её возникновения. Если не выполнить отладку системы, то в дальнейшем могут возникнуть дополнительные проблемы. Так как оповещение «В данной транзакции уже происходили ошибки» появляется при первом обращении, то в журнале регистрации данная строка обязательно зафиксируется, но, опять же, без подробного пояснения. Хоть ошибка и располагается на нижнем уровне кода, она нарушит необходимую иерархию. Это приведет к сбою других функций и только еще больше запутает администратора.

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

Неправильное отображение блоков формы

Такая ошибка «1С» может быть следствием разных факторов. Чтобы вернуть программу к работоспособности, попробуйте последовательно выполнить несколько команд:

• очистить кэш. Для этого необходимо перейти в папку, где хранятся временные файлы (путь к папке описан в пункте 3). Зачастую такая процедура помогает вернуть работоспособность программы «1С»;
• войти под другим пользователем. Можно использовать любой доступный профиль (лучше всего администратора);
• зайти в базу данных с другого ПК. Это действие позволит исключить ошибку, связанную с работой системы на определенном оборудовании.

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

При разборе обнаруживаем таймаут, согласно которому пользователь Иванов ожидает освобождения ресурсов

В тексте данного сообщения технологического журнала — находим номер соединения, которое блокирует ресурсы.

В нашем случае — это соединение 739428.

Причина ошибки «1с:enterprise integrity violation»

Изначально многие считали, что 1С начала очередную попытку заблокировать работу пиратских версий 1С. Ошибка «1с:enterprise integrity violation» возникала у всех в разное время, на разных платформах и конфигурациях. Закономерность сразу определить не получилось. Изучив логи и временные файлы стало понятно, что это не очередная попытка 1С заблокировать пиратские версии, а просто баг.

Открыв просмотр событий Windows, можно заметить, что вылет 1С:Предприятия происходил из-за файла v8_xxx_xx.1CBarcodWin64_9_0_12_13.dll, который располагался в папке C:\Users\USR1CV8\AppData\Local\Temp\.

Данный файл появляется там во время работы в 1С. Скорей всего разработчики выпустили обновление модуля работы со штрихкодами, которое не устанавливается или не догружается с серверов 1С. В следствии этого происходит сбой сервера 1С и он перезапускается с ошибкой «На сервере 1С:Предприятия произошла неисправимая ошибка» или «1с:enterprise integrity violation».

При выполнении на стороне сервера — «В данной транзакции уже происходили ошибки!»

Доброго времени суток!

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

Я сталкивалась с подобной ошибкой при выполнении кода на клиенте, и в этом случае спасало просто перезайти в базу — дальше все работало. А если на стороне сервера возникает эта ошибка? Каждый раз перезагружать сервер никто не даст.

Как сбросить эту ошибку, чтобы продолжить функционирование регламентного задания, почему ошибка могла возникнуть и как избежать ее повторения?

В основном такая штука случается, когда внутри одной транзакции оказывается другая, в которой собственно и присходит ошибка. Самый простой способ её увидеть: Открываем транзакцию, начинаем проводить документы, причем проведение стоит в Попытка-Исключение, чтобы программа не вываливалась. Какой-то докумен не может быть проведен и выкидывает ошибку, после этого Зафиксировать транзакцию уже нельзя.

Вывод — либо отказаться от транзакции, либо от обработки ошибок. Я выбрал отказ от транзакции в таких случаях или закрываю транзакцию до записи объектов (особенно если они типовые).

> продолжить функционирование регламентного заданияПродолжить никак. Лучше всего его полностью остановить и запустить снова.

«Продолжить — я имела ввиду не текущее выполнение регламентного задания, а работу рег.задания при последующих запусках. Кого остановить? Рег.задание?

Поясните, пожалуйста, подробней.Почему нельзя Зафиксировать транзакцию, если, к примеру, используется конструкция:

НачатьТранзакцию(); Попытка // проводим докумены Исключение // обработка исключения КонецПопытки;ЗафиксироватьТранзакцию();

И что значит «отказаться от отработки ошибок»? То есть, убрать из этой конструкции Попытку-Исключение?»

«> Поясните, пожалуйста, подробней.> Почему нельзя Зафиксировать транзакцию, если, к примеру, используется конструкция:> > НачатьТранзакцию();> Попытка> // проводим докумены> Исключение> // обработка исключения> КонецПопытки;> ЗафиксироватьТранзакцию();> > И что значит «отказаться от отработки ошибок»? То есть, убрать из этой конструкции Попытку-Исключение?

Представть, что ваша конструкция теперь выглядит так (просто есть кусок которого вы не видите — не вы его писали):

НачатьТранзакцию(); Попытка //Вот этот код где-то там — далеко в каком-нибудь модуле, да и 1С, что-то такое ведет в случае проведения НачатьТранзакцию(); Попытка //Здесь возникает ошибка Исключение ОтменитьТранзакцию(); КонецПопытки; ЗафиксироватьТранзакцию(); Исключение // обработка исключения КонецПопытки;ЗафиксироватьТранзакцию();

Так вот, если я правильно понимаю, то если вложенная транзакция закрывается, то транзакция верхнего уровня это видит и отказывается закрываться (возможно она уже тоже закрытая). В общем — кроме отмены транзакции уже ничего не сделать.

Вот и получается, что несмотря на обработку ошибки (исключения) — ошибка уже была и ничего с этим не сделать. Значит надо от чего-то отказаться. Или увидеть ошибку или убрать транзакцию.«

> Кого остановить? Рег.задание?А что у вас показывает «Консоль Заданий » по поводу вашего зависшего задания?

«1> НачатьТранзакцию();2> Попытка3> //Вот этот код где-то там — далеко в каком-нибудь модуле, да и 1С, что-то такое ведет в случае проведения4> НачатьТранзакцию();5> Попытка6> //Здесь возникает ошибка7> Исключение8> ОтменитьТранзакцию();9> КонецПопытки;10> ЗафиксироватьТранзакцию();11> Исключение12> // обработка исключения13> КонецПопытки;14> ЗафиксироватьТранзакцию();

В этой последовательности получается, что если мы попадаем на отмену транзакции в строке 8, то потом в строке 10 закрывается не внутренняя транзакция, а внешняя, и при закрытии ее повторно в 14 появляется ошибка. В данном случае, я бы предложила фиксацию внутренней транзакции перенести во внутреннюю попытку (в самый конец). Но это уже так, отступление.

Ок, в этой последовательности понятно, спасибо. Только будет очень трудно найти, где же оно в реальном коде ломается.

>> Кого остановить? Рег.задание?>А что у вас показывает «Консоль Заданий » по поводу вашего зависшего задания?

Вот «КонсольЗаданий» как раз и показывала в графе Ошибка «В данной транзакции уже происходили ошибки!». Правда, потом убрали Использование Рег.задания, а сегодня опять его запустили — ошибка прошла. Но есть вероятность, что сервер перезагружали, узнать пока точно не могу — это сервер нашего филиала в другом городе. «

Как провести исправление документа в 1С: ЗУП 3.1

Наверняка многие сталкивались с такой ситуацией, что в документе «Отпуск» или «Командировка» или в другом документе присутствовала ошибка: начисленные суммы уже выплачены, период закрыт, но документ необходимо исправить. В таком случае исправление возможно только через команду «Исправить».

В новом документе укажите корректные данные, после чего проведите и закройте документ.

Кстати, на нашем сайте в разделе Маркет42 есть специальная обработка – «Редактирование документов в закрытом периоде». С ее помощью вы сможете изменять некоторые поля в документах в закрытом периоде. Чтобы узнать, как работает данный сервис, ознакомьтесь с этой инструкцией.

Последние материалы

Плагин permissions 1.12. PermissionsEX — Управление группами. Управление правами групп игроков

И так, наверно у каждого из вас, кроме опытных держателей серверов имеются проблемы с настройкой прав доступа. Лично я использую плагин PermissionsEx, так как считаю что это самый лучший плагин распределения прав доступа для серверов.Что нам понадобится:.

Установить приложение в вк на телефон

Сотни миллионов людей пользуются данной социальной сетью для общения и развлечений, и на данный момент нет такого человека, который не слышал бы о ней. Для того чтобы легко получать доступ к своей странице этой социальной сети нужно скачать Вконтакте на а.

Как сделать граффити в ВК: раскрась стену разными красками!

Как в ВК рисовать граффити в сообщениях с компьютера? Это кажется невозможным, ведь все и так знают, что эту функцию убрали несколько лет назад, хотя она так полюбилась всеми пользователями еще с 2007 года. И только, о чудо, в 2017 году ее вновь ввели на.