Навело тема устройства на работу.
JOB: Проходили вы тест на IQ при устройстве на работу?

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

Я вот себя вспоминаю, самое сложное когда ловил сложные запросы с временными таблицами, которые еще гуляли между функциями.
Помню дописывал модуль, который помогал посмотреть на временные таблицы во время отладки.
А как у Вас было?

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

(0) сама конфа - сплошной большой баг ).

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

(2) как выявили?

(6) Методом дедукции. По дате старта процесса обнаружили периодические перезапуски рабочих процессов сервера. Начали изучать весь код, выполняющийся на сервере.

Однажды одна ошибка прикрывала другую ошибку два года. В итоге за два года регистры НДС заполнились криво. Решал не я - отдали франчам, франчи решали проблему 3 года.

(7) перезапускали из-за того что лимит памяти сжирали?

(9) бесконечная рекурсия обрушивает любой процесс. Если это клиентский процесс, он вылетает с дампом. Если это серверный процесс, то отваливаются все толстые клиенты, которые к нему подключены.

(8)[франчи решали проблему 3 года.]
не верю (с)
лажа откровенная

(0) в критическую секцию залетало 2 потока, хотя она была обмониторена. Не решил, переписал кусок один в один, заработало.

Пятно на мониторе. Воспринимал, как точку в коде.

Глючащая сетевуха на сервере. Dlink гигабитный с аппаратным ускорением, чтобы ему.. Из-за этого у людей база отваливалась и данные портились.

(11) Они решили перепроводить документы. А так как на тестовом севере перепроведение месяца занимало чуть больше месяца ...
Потом были вопросы организационного характера, что-то там с договорами и т.п.
Но вот недавно закончили вроде.

а по какому критерию оценивать?

Самый зачетный глюк был еще в 6-ке.
При начилении налога с продаж (5% для ньюфагов) неправильно округлял.
Выяснилось что глюк платформы, даже калькулятор неправильно округлял в определенном промежутке чисел.

(0) Баг 1С в процедуре расчета себестоимости ПУБ при общепроизводственных расходах, переходящих в виде незавершенки. В процедурах передавались туда-сюда туеву хучу раз ТЗ по 30-40 тыс. строк, с которыми в семерке работать крайне сложно. Пришлось кучу отладочного кода впихать. И сама процедура до нужного места доходила минут через 40 после запуска.

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

(0) Жалоба по телефону из цеха: "Опять у меня 1С не работает! Что у вас творится с программой?"

Дважды жаловалась. Прихожу - сетевой штекер валяется на полу.

Техничка шваброй сносила штекер. Задвинул комп поглубже под стол, чтоб ещё и диспетчерша ногами комп не пинала.

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

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

+(20) при умении пользоваться технологическим журналом, отладчиком и профайлером, прямо СЛОЖНЫЙ баг крайне тяжело найти. Они все - просто работа.

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

(21) "крайне тяжело найти" в значении "назвать крайне сложным крайне сложно какой-либо"

опять офигенно понятно получилось...

Помню ещё кто-то снял флаг "Основной отбор" у измерения регистра сведений. Сорвался запуск системы. Искали 3 дня.

Да, еще случай..
Замша ГБ сердито звонит: "не реагирует ни на какие клавиши, ни на мышь. Не могу работать в ворде после вашего обновления! Что вы сделали с программой? Исправляйте! нам работать надо!"

Прихожу - на клавише Esc углом положена тяжеленная папка с прошлогодними отчетами.

Аааа, вот еще была оборжака, которую три дни вытаптывали: v8: Возможно восстановить информацию из регистра сведений??? пост 15.
ДО сих пор улыбает при вспоминании

(27) У нас похожий случай был, и тоже с КИ, но ловили дольше, т.к. там была не древняя обработка, а вполне рабочая, но косяк с затиранием происходил только при нажатии 4-х или 5-ти кнопок в определённой последовательности :))

(25) а была бы система контроля версий - откатились бы.

Не связано с эской: реализация связи "многие - ко - многим". Говорили умные люди: вылезет ошибка - хер найдешь. Но мне было очень интересно попробовать...
Через 2 месяца работы (около того) вылезла ошибка. Искала 6 часов...
Неделю переписывала 2 модуля и переносила данные.
"Многие - ко - многим" не использую :)

(29) Мы все сильны.. сам знаешь, чем :)
Соломкой, и её отсутствием в нужный момент :)

(29) ты реально думаешь, что 3 дня ушло на откат галки?

Скорее, не баг, а фича в одной из функций компоненты FormEx. Благодаря ему, мне удалось написать довольно-таки большой код и много лет им пользоваться.
Короче его смысл в том, что в FormEx можно подключить правую кнопку мыши, и повесить на нее некие обработчики. Да вот беда. Ничего с текущим документом или справочником полезного сделать нельзя, ибо он заблокирован. НО! Мгновенно развернув окно формы на весь экран и обратно, получаем около одной микросекунды, пока сделать что-то можно. И в эту микросекунду вставляем обработку. Как я это нашел, хз, но я почему-то верил, что такое возможно, и все-теки нашел. Благодаря чему сделал универсальное меню, которе потом появилось в 1С 8.2/3 (Тип действия). Универсальное оно в том, что подключается к любой конфигурации с помощью пары процедур в глобальном модуле. (ну + компонента). Потом было найдено еще много решений.

(30) А если какая-то хрень реально связана "многие ко многим" как изворачиваться?

Не знаю, баг это или нет. Писал как-то здесь про видеокарту, что она взбесилась, что только ни делал. Потом о! чудо! стал шуметь один из вентиляторов, и ее приняли по гарантии, взамен дали точно такую же. Работает до сих пор без глюков. Самый прикол в том, что глюк воспроизводился ТОЛЬКО на моем компе, ТОЛЬКО у меня дома (в СЦ все работало, блъ!), и ТОЛЬКО на потоковом видео из инета, проигрываемого не в HTML5. Доказывать, что я не верблюд, приходилось долго.

(26) баян :)

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

(34) у нас в ЕГАИСе сейчас такая хрень, хорошо, что пока не было совпадений именно в многие-ко-многим, все случаи соответствия либо в одну, либо в другую сторону. но рандом когда-нибудь к этому приведет.

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

(34) Всегда можно заменить "один-ко-многим".
(38) При разборе полетов выяснилось, что ошибка возможна "один на миллион" (типа того). Но вылезла очень быстро, что и спасло - когда прошел бы "миллион" пришлось столько лопатить...
Когда в ЕГАИСе вылезет - будет полный капец :(

вот у меня прям щас непонятный глюк.
была себе рабочая такая диаграмма ганта...

добавил условия фильтра при выводе сириий-точек. проверяю, даныые пропали, таблица пустая выводится.
Убираю написаныый код, данные не появляются, опять пустая таблица. 15 назад ДО кода все было )

(39) Видимо, 1С теперь решила специально для вас фичу с DoNotCopy сделать для того, чтобы с это хренью не мучиться

(39) Заведите константу "Список рабочих серверов". При старте проверяйте имя текущего сервера и константу. Так вы сможете определить, рабочая это база или тестовая. И соответственно выключить опасные сервисы.

(43) а если копия развернута прямо на сервере?

(44) Тогда можно завязаться на имя рабочей базы.

(40) Мне реализация такой связи без вспомогательной таблицы не попадалась. Какие-то субд её поддерживают нативно?

(45) кстати, у вас на форуме баг. сообщение
ОШИБКА: Сработал фильтр на язык ******** на слово ***. Пишите по-русски!
появляется только если обновить страницу, после ввода текста просто ничего не отправляется, но и сообщение не выводится.

(47) +хром последний, чистый, но с адблоком, вин х7 64, кис.

Странно, но ничего в голову не идет, баг он пока не разрешим баг, а потом решаешь и нет бага и как о всём плохом забываешь

(49) старый баг лучше новых двух

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

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

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

Был один забавный баг, связанный с жестким диском. Уже не помню зачем, но зачем-то разобрали системник, то ли почистить, то ли память поменять/добавить, но суть не в этом. Когда сделали все что надо было сделать, перед тем как закрывать сделали контрольное включение - все работает. Закрыли корпус, включаем - говорит, что не видит "винт". Открываем, снимаем "винт", для начала передергиваем разъем и не прикручивая обратно включаем - работает. Ставим "винт", закрываем корпус - не работает.
Открываем корпус, снимаем "винт" (не отсоединяя шлейф) - работает.
В конце концов выясняется, что когда прикручивали "винт" перепутали крепежные винтики и взяли немного длиннее, чем был изначально и этот длинный винтик уперся в торец платы контроллера и что-то закоротил. Заметили случайно - когда в очередной раз прикручивали винт на место.

(36) Самолично такое встречал. Пришел, увидел, улыбнулись )))
А вчера коллега рассказал - смеялись всем отделом: Один общий знакомый рассказывает, что пришел к юзверю и в его отсутствии протер экран от пыли, ибо там слой был в сантиметр! Стало хорошо все, кроме того, что юзверь чуть в обморок не упала - она оказывается три месяца эту пыль копила на экране, так как ей было очень ярко!!!! На вопрос "а кнопочками попользоваться не судьба?" Невнятно мычала ))))

(44) Используй строку подключения. Там все есть.

(61) Кстати, в типовой БП это уже реализовано.

(63) Это не отменяет того факта, что объекты в бизнес-логике реально имеют связь "многие-ко-многим".

(39) Да уж, неотключенные регл.задания в копии базы это классика, тоже наступали на эти грабли...

(18) UnitTest с ассертами))

УТ 11 один сплошной баг.

Наверное одно из самых неприятных был поиск зависаний 1Ски. Когда просто на 30 - 90 секунд 1Ска у всех не отвечала в случайное время. Загрузка что сервера 1С, что сервера sql отсутствовала. Причем вообще в ноль уходила временами. Специально мониторили, в момент зависания ни ЦП, ни память не упирались в предел. Более того, они показывали очень низкие результаты по использованию.  Потом догадались снимать дисковую очередь. Оказалось что она в моменты таких завалов вполне ощутимая. Посмотрели, что так напрягает. Оказалось чтение файла журнала регистрации. Как итог отказались от журнала регистрации в формате SQLite.  Уж больно непредсказуемо и непонятно для нас работает (увы, не хватило знаний, разобраться почему такая деградация при чтении, обрезание журнала было настроено, но видимо надо было что-то еще делать с ним). Перевели его на старый файловый вариант, с обрезанием каждый месяц. Стало получше.

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

Вспомнил недавний баг, не самый сложный, но запомнившийся (разработчики Коруса, если вы тут, ау, вам привет):

есть у такая приблуда - EDI-адаптер и там вся "кухня" варится на текстовых файлах. И некоторые юзеры грузили проц на 10-15%, что в итоге приводило к подвисанию терминала. Выяснилось, благодаря Process Monitor, что к одному файлику обращаются все клиенты и из-за FILE LOCK CONFLICT происходит перегруз процессора.

Идите в баню со своими многими ко многим, теоретики.

Делали расчет СЧА(ежедневный).  При отсутствии котировок биржи(например, в выходные) СЧА формировалась расчетным методом. Дорабатывал этот модуль в части НКД и забыл пересчитать из валюты в рубли и получилось, что СЧА формировалось из рублевой оценки ЦБ и валютной НКД. т.е. складывались рубли с долларами в одну сумму и эта сумма попадала в проводки, по которым формировался отчет по портфелю клиента.
Об ошибке узнали только через полгода.

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

Потратил в свое время день на это. Запросы к DBF через ODBC возвращали часть полей пустыми. Оказалось через 1с7.7 были текстовые реквизиты были сделаны конской длины, а ODBC не читало такие поля, которые превышали 256 символов по стандарту DBF. Просто запомнилось как голову ломал че за фигня.

На заре карьеры, главбух жаловалась на мышку. Что та как то странно реагирует. Сама перемещается по экрану.

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

Глюк был следующий. мышка была еще с шариком. И в щель между кнопками проникал солнечный свет, который сводил с ума сенсор.

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

(0) Охотница?

Мой самый большой баг ещё впереди. Это будет когда я открою конфигуратор, посмотрю и скажу: - Ой, всё!
А потом закрою его навсегда.

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

(60) многие дешевые lcd мониторы при уменьшении яркости начинают моргать подсветкой из-за дешевого ШИМ. И от этого быстро устают глаза.

(68) этот баг недавно привнесли и недавно же починили

(75) Было недавно похожее )

Мышка сама дергалась.
Поменяли, все равно дергается.

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

Был баг - жму на ярлык 8.3, запускается 7.7 и так не один десчток раз. Проснулся в холдном поту...

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

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

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

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

(0) Вот вот  :) Посмотрел  на это (таблички временные и прочее) и реализовал на стороне скуля  хранимую процедуру с основным расчетом .  Теперь средствами скуля можно смотреть что  именно выполняется в хранимке   , а не смотреть в профайлер и видеть  select * from #ttt45  или #tt444446 . А что в этих пронумерованых тэшках и не понять :)

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

Ну вот сейчас баг сисадмин бъется, начали переписку в одноэс
Пока результата нет
Суть
Под сервером вин2003 на ослике 8 версии не открываются одноэсные сайты по https

А так вообщем и не припомню чтото кардинально сложного
Тяжелее всего когда приходится работать с какимнить черным ящиком
И бесит когда в какомнить софте находишь ошибку, а ее не исправляют

(89) На 2008R2 это сделалось в три нажатия: генерация сертификата, привязка к новому порту и рестарт веб-сервера.

(91) никаких веб-серверов вроде не поднято. что перезапускать? и что значит "привязка к новому порту"..?

Помню какой-то типовой  отчет на скд связанный с основными средствами выдавал некорректные остатки или обороты причем полностью.
2 дня разбирался, оказалось что в документ по ос неправильно ввели счета учета по амортизации т.е. Вместо 02 - счет 01.
А в отчете запросом определялись список счетов ОС и список счетов по амортизации по заведенным регистрам или документам. и там и там попали счет 01. В результате отчет выдавал полный бред.

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

Я в СКД словил глюк, когда для ресурса задание выражений итога "КакоеТо_Выражение" и "КакоеТо_Выражение + 0" приводило к разному результату. А отчет был в целом сложный, я два дня убил на эксперименты, выясняя, что не так.

Сегодняшний баг, претендует на самый сложный. Сложный запрос, сложня компановка. упрощал до абсурда и результате вышло следующее:
СКД запрос, результат 1 строка, Есть поле булево со значением ИСТИНА, и некая ссылка. Делаешь отбор по значению этой ссылки ИСТИНА меняется на ложь.
Что помогло: добавил еще одно поле с кодом:
Выбор когда истина тогда НЕКАЯСсылка конец КАК ТЕСТ.
Делаешь отбор по значению поля ТЕСТ - все ок, делаешь отбор по значению НЕКАЯссылка меняется значение булева типа.
Ни разбор пакетов на вложенные запросы, ни прочие приемы, которые помогают при чудачествах оптимизатора не помогли.
После этого опять собрал сложную компановку и все ок при отборе по новому полю, а по старому опять ерунда.
Причину так и не понял.

После выставление в документе даты на 21.01.4000 не рассчитывалась сумма в документе. Ну и документ не провёлся. оказывается по логике 1с, 3999 это что-то вроде ТА. Вылечилось перезапуском.

(90) "И бесит когда в какомнить софте находишь ошибку, а ее не исправляют"
Угу. Или пишут в ответ на багрепорт. "У вас использован лимит на одно обращение в техподдержку в месяц, мы не можем принять ваше сообщение к рассмотрению". Спросил "что за фигня, я не прошу консультации, я сообщаю об ошибке" - ответили "по нашим правилам любое обращения считается консультацией" и идите лесом, нам ваши багрепорты не нужны.

Самый сложный баг - это когда пришел на собеседование и задают такого рода вопросы.

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

На прошлой неделе тоже наткнулся на интересный баг с округлением в запросе в скульной базе.
Оказывается, что обычные (не форматированные в запросе) числа после операции деления (в моем случае) скуль автоматически округляет до 6 знака после запятой. И у меня результат отличался от оборотки на несколько рублей.
В файловой версии все было нормально.

Заявка пользователя - "1С не принимает пароль". Километр бежал к пользователю чтобы нажать NumLock. Вторая заявка - "У меня не работает 1С". Прихожу. Пользователь - Подключите мне принтер пожалуйста.

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

(101) Ну кстати баг округления есть в типовом запросе 7.7
Было как-то что из запроса приходило число со 0 знаков после запятой, а мне надо было 2 знака после запятой.

Помогло так

|Значение = Значение + 0,01 - 0,01

Помог с этим Ёпрст

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

(101) Вспомнил есть еще глюк в типовой БП 2.0, да и 3.0 наверное тоже.
Курсовые разницы создают расхождение на 0.1 если оплата авансов за поставку идет не 1 платежом, а 2мя и более и не в один день, а в разные дни.

(105) Да, вроде такой баг был в табеле в ЗУП. Там делался запрос без явного упорядочения, а выбирались данные в предположении конкретного порядка. На файловой всё работало, на sql - зависело от фаз луны.

(107) именно в ЗУП было, верно.
Разрабатывали с товарищем доработку документа - он в офисе в файловой, я на месте у заказчика. Показывает у себя - работает, скидывает конфу, ставлю на раб. базу - не то, хотя базы и конфы - идентичны! Когда увидели результаты отладки там и там, не помню уже плакали или смеялись.

как-то заблудился в веб клиенте в 3х строчках в веб клиенте

v8: v8: получаю разное число (1коп) в web и тонком клиенте

(104) И чем же это помогло?

А есть ли тут такая тема, где собраны все встречающиеся баги по конкретной конфе?????

(104) У меня было похожее, только это был не просто запрос, а запрос, который я делал в другой базе через OLE. Мне повезло меньше. Никто не подсказал. Пришлось в тексте запроса все значения умножать на 100. А после получения - делить :-)

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

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

(0) Еще как то в ту же хлебобулочную конфу интергрировали EDI от "Контур", который в виде обработки.
Поскольку есть несколько баз (заказы, экспедиции на заводах, центральная база учета реализации), то между ними идет постоянно обмен.
А в Контуровской обработке совершенно не учитывается то, что при записи чего-либо может произойти блокировка. Там при приеме-отсылке документа идет последовательно запись в разные регистры, и если в какой-то момент происходила блокировка, то все это "незавершенное производство" зависало в таком нецелостном виде.
Пришлось в этой обработке везде где надо реализовывать работу в транзакции.

(111) Не взлетит. Тут ограничение на 1000 постов.

(110) Ник смени.

(0) мой самый сложны баг еще впереди. Живу и наслаждаюсь жизнью