Вылет 1С SQL при одновременном создании документов #512624

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

Похоже на дедлок...

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

И вылет не с дидлоком, и в SQL-е включено логгирование, и нет дидлока.

Я наверно сделаю на блокировке служебного справочника. В вводнового - заблокирую, вопрос когда и как разблокировать?

А что пишет при вылете? Что пишет в трассировке?

Смоделировать не получается, получается посмотреть скриншот. В журналах ничего нет. Вылет - Ошибка приложения, исключение 0xc0000005  в приложении по адресу 0x1f208b71

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

На сутки парализовать работу фирмы?

Это скуяли™?

я тебя не понимаю. точное время вылета известно.

Вылет раз в сутки. То есть я на сутки включу на SQL-е трассировку.

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

Ну, я как-то трое суток писал. И ничего :-) контора работает в режиме 24*7

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

Скорей всего проблема при блокировке файла - как известно, SQL-версия всё равно в директории создаёт файлы и что-то в них блокирует (чтоб ей там пусто было - в SQL реализовать поленились). Далее, если с блокировкой файла что-то не так (сеть сглючила и т.п.), то имеем проблемы.

При этом нет вылета

Вопрос, почему вылет только при одновременном создании двумя операторами документа одного вида, и вылет не в момент создания! А в момент записи.

если "сеть сглючила" - он получит "объект <а тут вновь созданый объект> заблокирован".  Как с этим бороться - проскакивает периодически - ума не прриложу. Началось повторно месяц назад, и уже все перепроверили - найти не можем

На одной машине или на разных ?

вопрос даже не в этом. Вопрос в том - почему именно вылет без всяких внятных сообщений...

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

В сделано предположение.

ну и поставь в трассе фильтр - посмотришь, вообще до инсерта в 1сджорнал дело доходит или нет...

Вылет без внятных сообщений бывает, если наблюдаются какие-то проблемы с внутренней структурой данных в 1С. Например, если переполнить стек вызовов, то приложение закроется аварийно. Если же мы читаем-пишем память, которая ещё не выделена (или уже свободна), то получаем сообщение об ошибке доступа. Кстати, а номера заявок получаются совпадающими ?

Что касается внутреннего кода: Внутренний код, насколько я знаю, присваивается не в момент создания документа, а в момент его записи. То есть, если создан новый документ, то он известен только данному клиентскому сеансу, для другого сеанса его нет. Другое дело, что при записи документа должна проверяться уникальность номера документа (а проверяется ли она), если нет, то в SQL-вполне вероятно, что индекс уникальный. Теперь, когда мы что-то пишем в базу, то SQL нам напоминает, что нельзя записать два документа с одинаковым номером - и второй всегда "отваливает с ошибкой". Проверить можно просто на тестовой базе - присвоить одинаковые номера при помощи "DocNum=1" и попробовать записать - если второго записывающего "отвалит", то мы поняли в чём дело.

не путай ид и код.

Да, в момент создания (в журнале регистраций) в момент записи они уже разные.

Таки что там путать - у документа вообще кода нет. А по какой причине меняется номер документа ?

В коде прописано, ибо до этого были дубли.

Откуда же периодически появляются Айди-двойники?

от индексов

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

Семёрка при создании нового документа не присваивает ему ID - только номер. Номер хранится в таблице открытых документов, а ID присваивается только в момент записи. Если где-то выполняется блокировка журнала и т.п., то новый документ будет создан только после снятия этой блокировки - причём вероятность совпадения возрастает. Открой транзакцию, поменяй что-то, и жди несколько секунд (2-3 чтобы не вывалилось с ошибкой), а за это время на двух других клиентах создай документ - и посмотри, что происходит.

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

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

ла точно из-за одновременного создания. Ибо вот такой кусок в ВводНового, и и в ВводНаОсновании (с отпусканием блокировки в конце процедуры приоткрытии) Проблему полностью решил. Если  глслужспр1.блокировка=0 тогда статусвозврата;

уверен. у вас скл >=2005

+ паченный

Да, 2000-ый. Со всеми официальными патчами.

Я многократно писал в ветках как я отношусь к >2000 под семерку.

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

Хочется поскандалить? Вы тоже в Уверены, но жестоко ошиблись. И вы тоже не звезда.

скорее всего это связано с получением номера документа

Но почему вылет не в момент получения номера, а момент записи?

хотя нет. там индекс включает row_id

Круто, второй Гений1С.

как это почему? потому что конфликт уникальности при записи происходит, а не при чтении.

Номер документа уникальный на скриншоте вылета. Присвоенный согласно префикса фирмы (не тот, который в момент создания по ЖР)

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

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

плавающие ощибки - самые неприятные. особенно с учетом  их увеличения скорости появления. попробуйте мониторить с помощью скл профайлера. на моей памяти нет подобных проблем. просматриваю форумы т1с с 2001 года,   мисты - с 2004. надо понять что изменилось до периода с начала диагностики: урбд, репликация, вставка данных прямыми запросами. те возможно происходит рассинхронизация с таблицей зарезервированных номеров  по причине отключенной блокировки. и с возрастанием количества вводимых документов папалельно мб проблемы. эксплуатаровал 1с77 + скл 2000 + габкие блокировки. 250 пользователей. такой проблемы не было. зато были 1с77 + скл 2005. вместо апа.

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

Вот скриншот

Делай свои вычисления не в Процедуре приОткрытиии а в ПослеОткрытия ( процентов на 90 что все пропадет ) Также ничего не было сказано док Заява проводится или нет. Если док проводиться то Проводится ли при первой запист.

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

ПослеОткрытия в семерке? Док в базе не появляется, значит даже запись не производится, на ней вылетает. Так проблема ведь решена. Зачем менять? Теперь до сути, из-за чего она происходит хотелось бы докопаться. Я думаю что проблема не в номере.

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

>>>С чем это связано? Обоим документам присваивается >>>>одинаковый внутренний код? Как это можно обойти? Назовите точное колонки и таблицы поля внутреннего кода а то если чесно не уверен что точно понимаю о каком поле речь.

выкидывай блокировка и заменяй их на пользовательские блокировки sql ( которые на уровне сессий ). Твои "глслужспр1.блокировка" при интенсивной нагрузке дают сбои.

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

(60 ) Я же написал в 59 ИХМО. Основа этих блокировок файловая.блокировка она может не поспеть за множеством sql блокировок. Ответь на

Я сам не знаю, поэтому и спрашиваю. Насчет сбоя, для штрихкода используется уникальный код. В глобальнике вот такая процедура. Текущий номер  1 455 256 Сбоев не было, ни одного дубля, ни одного пропуска, ни одного вылета, все вылеты были определены причины (до этого - дидлоки на справочнике договора), не определены причины только текущего вылета, хотя ситуация исправлена.

Ну если  Вы не знаете  что означает фраза >>>Обоим документам присваивается одинаковый внутренний код то я тем более не могу этого знать. Где дальше используется этот код  ??? При выполнении кода : идет блокировка таблицы констант. с точки зрения интенсивной работы пользователей код лучше переписать так

компоненту ромиска надо было попробовать убрать для начала :)

Низзя :( Либо нужен другой выход, но это всё намного хуже. Этот код выполняется настолько быстро, что блокировка ни на что не влияет.

он остался от предыдущего, как раз глючного способа - попытки блокировки таблицы констант.

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

весь код из можно заменить на гораздо лучший с точки зрения sql CONSTRAINT PK0_Table_X  PRIMARY KEY (id) ) В таблице одна строка Далее читаем значение

Начатьтранзакцию - Зачем лишние транзакции в базе?

нет в коде лишних транзакций. но нет и обработки ситуации, когда заблокировать не удалось.

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

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

в нашей базе тоже каждый день юзеров из несохраненной ЗаявкаПокупателя выкидывало. Вопрос закрыли, добавив      КонецЕсли; Таким образом - тема закрылась. Чем быстрее документ будет записан, тем меньше на подобный 'вылет'.

Кстати, была подобная проблема - отваливание вайлов блокировки, в основном журнального. ПОтом - пропало. ПОсле очередного пакета обновления от мелкомягких - опять появилась, и месяц уже преследует...

дополнение к . На вопрос Записать заявку (Да-Нет?) юзеры иногда отвечают нет (когда им нужно 'прикинуть по сумме черновик'), поэтому лишних заявок в базе наша команда Записать не плодит.

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

+ или периодики зы. я вообще константы кэширую. Долго с ними работать...

В системе только одна константа изменяется.