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

>>>>Далее, по потоку выполнения, эти параллельные ветки могут снова сходиться в один поток, а могут и не сходиться.

это как они могут не сойтись? тут у тебя ошибка в логике...

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

(1) Какими способами можно реализовать эту задачу, кроме ручного, естественно?

1 вместо одной задачи сделать 2, в каждой задачи вложеный БП

(3) Мне не нужен вложенный бизнес - процесс, БП у меня один, мне нужно чтобы 1 БП разделился на несколько потоков. Можно привести аналогию с процессом и потоками выполнения внутри процесса в компьютере. Процесс в любом случае один со своим адресным пространством, а внутри него выполняются несколько потоков.

4+ Вложенный БП не подойдет хотя бы потому, что граф выполнения бизнес - процесса заранее неизвестен, на каком действии БП должен разделиться на 2, 3, 4 потока выполнения, где они снова сойдутся в один поток, и сойдутся  ли вообще до точки окончания БП - все это проясняется только лишь при выполнении уже запущенного БП. То есть у меня нет возможности даже описать вложенный БП, он неизвестен.

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

еще там есть спец блоки "разделение" и "слияние" но по факту они работает очень странно.

опиши реальную задачу, вероятно ты что-то просто не догоняешь,

(6)+ я давно реально использую БП (уже лет 15 наверно)

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

(6) БП описывает перевозку грузов по железной дороге. Под перевозку заказывается несколько платформ, например, 10. И чтобы перевести грузы на этих платформах нужно выполнить несколько этапов: составить договор с собственником, оформить ГУ - 12, заадресовать эти вагоны, подать на фронт погрузки, подать на фронт выгрузки, вернуть вагоны собственнику. Это очень очень упрощенно.

Особенность заключается в том, что практически на каждом этапе может произойти разделение БП на параллельные потоки. Например, оформили ГУ - 12 на 7 вагонов, по этим 7 пошли дальнейшие действия: адресация, подача на фронт погрузки и так далее. А по остальным 3 вагонам ГУ - 12 будет оформлена позже, соответственно все эти действия (адресация, подача на фронт погрузки ...) должны тоже выполниться, но позже, может через дней 10 только.

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

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

(9) Ну значит у тебя они разделились на 2 в рамках одного заказа

На 2 чего?
И разделится могут (и так происходит на самом деле) на 5 - 6 - 7 потоков, и где разделятся сказать заранее невозможно, и где сойдутся тоже, и сойдутся ли вообще до окончания БП.

почитай про IDEF-0 попробуй нарисовать свой процесс в этой нотации и поймешь, что это не один БП а много и разных

(12) Пусть будет так. Вопрос в том, как эти вложенные бизнес - процессы организовать в 1С если заранее неизвестны ни точка старта этого вложенного процесса, ни точка окончания?

(13) циклом

(14) Каким циклом не подскажешь, я в 1С новичок еще...

примерно как на правом рисунке http://images.myshared.ru/4/287599/slide_17.jpg

(16) +
на этом рисунке "согласование" это вложенный бизнес процесс

там 2 уровня, у тебя будет минимум 3 уровня вложености

распиши все операции которые возможны

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

потом перерисую заменив объедененные куски некими кружками (БП) полученными на предыдущем этапе, повтори предыдущий этап

и так далее

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

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

(19) не красиво получится если ты нафигачишь портянку из всех вариантов.

БП должен состоять из небольшого количества элементов (от 3х до 10), если у тебя больше - это херня а не БП.

еще раз - начни с описания всех точек контроля/операций, просто список напиши... и в нем проставь "+" на те точки где может идти разделение, и выложи сюда.

(19) Начни с базиса- с понимания что такое бизнес процесс

(20) У меня в процессе на двух десятках действий может произойти разделение процесса на потоки, вагонов - то в реальности под сотню, заадресовывать их могут по 5 штук. Потом се это может слиться в один поток, но так редко происходит. Неужели ты не чувствуешь интуитивно что твое предложение некрасиво, громоздко, запутано? Я на C# за 2 недели сейчас напишу компоненту, которая очень красиво разрулит все сложности с помощью обычного ориентированного графа. Зачем мне весь этот геморрой?

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

ты спросил про БП в 1с, я ответил....

твою херню не обязательно решать через БП, можно сделать через статусы и регистры

а вот за 2 недели через C# на компоненте это решить - я в это не верю, там и за 3 месяца не сделаешь хорошо...

вообще вся твоя задача скорее всего не является БП вообще... как я ранее говорил - нарисуй ее на бумажке по правилам IDEF-0, тогда поймешь что к чему...

дарю, почитай https://studwood.ru/1869291/informatika/proektnaya_chast

(24) За ответы спасибо большое, ты мне помог убедиться что в 1С механизм БП не решает мою задачу. То что ты предлагаешь - паллиативное решение, то есть неправильное, но вынужденное к применению. Это связано, конечно, с тем, что 1С - ники в силу косноязычности и невыразительности платформы 1С вынуждены придумывать весть этот геморрой. Ведь подумай сам, через полгода надо будет внести в мой процесс изменения, и мне придется сидеть и перетряхивать весь этот механизм, а моему работодателю оплачивать мои упражнения. А в это время идут отгрузки...... Бр........

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

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

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

а твои проблемы в том, что в твоем понимание БП - это граф, и в этом ты не прав.

Бизнес процесс всегда состоит из блоков, каждый должен иметь 4 составляющих

Входные данные (ресурсы)
Выходные данные (результат)
Исполнителей (не обязательно люди)
Руководителей (не обязательно люди)

Кроме тго БП должен иметь начало и обязательно конец

Кроме всего прочего БП подлежат обязательной декомпозиции


У тебя в понимании нет
1. декомпозиции
2. обязательности завершения
3. управления каждым этапом

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

Это из той-же оперы как просят бухгалтера вывести 100 тысяч строк отчета в ексель,
их спрашиваешь - зачем?
они говорят мы там будем фильтровать!
А разве в 1с нельзя фильтровать?
а мы привыкли в ексель!

так-же и ты привык к графам (видать из института еще), а в 1с другие подходы, не хуже а именно другие.

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

(28) Нет уж, пусть пишет на СИШарпе

(28) Чел с 1С недавно познакомился, а ты хочешь, чтобы он работу архитектора сделать мог? :))

есть же разделение и слияние
если заранее не известно то сделй условие. в одной ветке без разделения в другой с разделение

(31) Это очень громоздко, потом вспомни, что мой БП может разделиться на неопределенно большое число потоков, каждый из которых может самостоятельно дойти до последнего действия - выписка отгрузочной ведомости для бухгалтерии. Часть потоков может сливаться в заранее неизвестных точках маршрута. Здесь решение только одно просматривается - моделировать бизнес - процесс с помощью ориентированного графа, узлами которого будут действия БП. Этот граф будет расти по мере выполнения БП, отдельные его ветви будут соединяться, если точки графа будут на одном уровне. Например, 100 вагонов разделились на предшествующих этапах на группы по 20, 30, 10, 30, 5, 5 вагонов. Это могло произойти на этапе формирования ГУ - 12, на этапе адресации, на этапе подготовки вагона к подаче на фронт погрузки, на этапе приемки вагона на соответствие нормам ТУ. А на этапе подачи на фронт выгрузки, часть вагонов снова оказались вместе, например, это первые 20 вагонов и последние 5. И это очень упрощенная ситуация. Представляешь сколько вариантов всего может быть? Посчитай количество перестановок из 100, то есть 100!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Вопрос у меня был один: возможно ли с помощью стандартных 1С средств работы с БП смоделировать мою ситуацию? Я изучил документацию по БП и понял что нет, нельзя. Но на всякий случай задал вопрос на этом форуме. Понял что на самом деле нельзя, буду писать COM компоненту на C#. Не вижу ничего сложного в этом, алгоритмы работы с графами давно всем известны.

зачем тогда вообще нужен бп?

какой нибудь партионный учет никто же не пишет на бп

(33) БП в 1С позволяют с минимум затрат построить пользовательский интерфейс, не хочется на это время тратить. Если бы в БП 1С был бы механизм, позволяющий строить карту маршрута на лету, по мере прохождения точек маршрута, вообще все замечательно было бы.

А при чем здесь учет по партиям? В моем БП есть достаточно существенная статическая часть, ее я реализовал стандартными задачами, а при достижении первой точки действия где возможны разделения/слияния я отдаю управление моей компоненте, потом идет опять неизменяемая часть БП, я снова возвращаюсь к стандартным средствам 1С.

36+ Но все же очень жаль что нельзя карту маршрута строить динамически

(32) ты описал не бизнес процесс а просто процесс, разницу понимаешь?

твоя задача решается на нескольких регистрах и кучи документов,

банально примерно так

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

при этом на любом этапе можно списать всю сумму а запланировать уже в нескольких или других разрезах аналитики


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

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

(37) карту маршрута МОЖНО строить динамически, только тебе не советую, опыта у тебя мало...

в любом случае прежде чем делать подумай ГДЕ будешь хранить данные по этапам?

единственно правильный вариант - регистры, если ты рассматриваешь любые другие варианты - то ты ОЧЕНЬ сильно не прав.


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

(40) Данные по этапам я храню в отдельной базе на сиквел сервере, доступ к данным через COM компоненту. 1С регистры не позволяют использовать триггеры, настроить оптимально индексы. Как их вообще можно использовать в серьезных проектах?

(41) зачем тебе 1с ?


pc
зачем тебе тригеры когда есть подписки на события?

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

это примерно как я пытался-бы автогеном фрезеровать детали...

(42) Затем, что ограничения целостности надо проверять в триггерах, а не в каких - то там подписках. Это основы работы с СУРДБ. Твое непонимание простительно, конечно, ведь у большинства программистов 1С нет специального высшего образования. Они искренне удивляются тому в чем совершенно не разбираются.

(41) ты вообще понимаешь,  что своей херней ты
1. напрочь убиваешь контроль ссылочной целостности (это вообще супер преимущество 1с перед всеми остальными конкурентами)
2. делаешь поддержку ситемы супер сложной
3. закладываешь проблемы в целостнось бекапов (отсутствкие синхронизации)
4. убиваешь систему блокировок и транзакций 1с (пытаясь перейти на блокировки и транзакции SQL ты делаешь не возможным использовать кластер 1с)

я могу еще с десяток пунктов привести...

(43) жесть... прям все пункты жесть...

я не говорю, что ты не понимаешь в СУБД, судя по всему понимаешь, но ты не понимаешь в 1с, в ее архитертуре...

ты понимаешь как устроены блокировки 1с в КЛАСТЕРЕ серверов 1с ??? ты понимаешь, что там невозможно использовать большую часть механизмов СУБД? а теперь подумай - зачем так сделано?

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

(46) легко... во первых это можно делать штатно в циклах, о чем я писал ранее но ты так и не понял идею.

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

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

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

(47) Я сейчас еще раз прогуглил с запросом "Программное создание карты маршрута 1С" и не нашел никакой информации по этому вопросу. Не поделишься ссылкой? В книге "Профессиональная разработка в системе 1С Предпритие 8" в разделе, посвященному бизнес - процессам, тоже ничего нет....

https://www.yandex.ru/search/?text=1с%20карта%20маршрута%20программно&lr=118989

если уж первоисточник - вот https://its.1c.ru/db/metod8dev#content:2336:hdoc

и это почитай https://its.1c.ru/db/metod8dev#content:2346:hdoc

(51) если уж первоисточник - вот https://its.1c.ru/db/metod8dev#content:2336:hdoc

Внутри статья "Программное формирование ЗАДАЧ"

Мы разве говорим о задачах? Мне надо добавлять/удалить точки на карте маршрута?

(52) и это почитай https://its.1c.ru/db/metod8dev#content:2346:hdoc

Я тебе про Фому, а ты мне про Ерему.

Еще раз говорю, мне не нужны вложенные бизнес - процессы. Мне надо ПРОГРАММНО по ходу выполнения БП изменять его карту маршрута. Как это сделать?

(54) Но ведь не прям произвольно изменять, все равно логика ветвления и модификации будет либо в коде зашита, либо во вложенных БП

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

(56) Мне не подходят вложенные БП по четырем причинам:

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

2. После каждого выполненного действия потоки могут снова соединяться в один БП, то есть выполнилось одно действие вложенного БП и он вдруг стал совсем не нужен, а надо просто объединить 2 - 3 - 4 - ... - n потоков а один

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

4. Неизвестно на сколько независимых потоков разделиться БП

(57) "дополнительные точки действий могут быть самыми разнообразными" // Ну так если бы это было кодом, то ведь все равно заранее известны эти "кирпичики" из которых будет строиться

(57) "выполнилось одно действие вложенного БП и он вдруг стал совсем не нужен, а надо просто объединить 2 - 3 - 4 - ... - n потоков а один" // Ну, а какие проблемы? Механизм БП это позволяет

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

(57) Столько "неизвестно заранее" намекает на плохое моделирование предметной области.

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

(60) я тебе описал реальное решение в (38) это решение позволяет контролировать числовые значения различных аналитик на различных этапах, такое решение применяется например в УправлениеХолдингом для план/факт и контроля исполнения (нескольких статусах) данных.

Вообще можно реализовать даже на 1 регистре следующего содержания (правда я не советую на одном его закрывать будет тяжело)
измерения
1. аналитика (номенклатура)
2. партия (минимально неделимый размер)
3. этап
ресурсы
1. количество
2. сумма

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

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

вывод - не умеешь использовать 1с - работай на с# чего ты и делаешь, продолжай дальше, только не пойму чего ты на фроуме 1с ников пытаешься выяснить?

(63) +

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

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

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

(61) Столько "неизвестно заранее" намекает на плохое моделирование предметной области

Ничего подобного. Просто вам не приходилось сталкиваться с реально сложными заранее неопределенными БП. Автоматизация пивного ларька и ж/д перевозка груза на 100 платформах из Китая на Украину, очевидно, различаются по сложности. Не правда ли?

(66) бизнес процессов с неопределенными данными или результатов не бывает, так сказать по определению


https://ru.wikipedia.org/wiki/Бизнес-процесс


--------------------------------------------------------------------------------
цитата: Бизнес-процесс — это совокупность взаимосвязанных мероприятий или работ, направленных на создание определённого продукта или услуги для потребителей.


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

о чем я тебе твержу и твержу, твои графы не подразумевают декомпозицию и складывается ощещение, что именно ты не автоматизировал ничего крупнее пивного ларька если не понимаешь зачем нужна декомпозиция (в парадигме 1с - вложенные БП)

--------------------------------------------------------------------------------
цитата:
BPMN — функциональная последовательность работ;
EPC — событийная последовательность работ;
IDEF0 — логическая последовательность работ;

тебе или IDEF0 или EPC подходит, нарисуй в них всю схему, если ты не можешь нарисовать и ссылаешся "они там такое навертят" то это не БП а бардак, и его автоматизировать инструментами для БП просто глупо.

Пойми - неопределенности уложить в БП теоретически нельзя, по тому как это получится НЕ БП.

(67) " бизнес процесс всегда имеет результат"
Я поместил объяву на доске. БП начался. Какой его результат на текущий момент?

(68) это не бизнес процесс по определению

я начал есть суп - какой результат этого бизнес процесса?
я сел на толчек - какой результат этого бизнес процесса?  

:)

(65): ну вот и объяснение всему нарочитому непониманию и раздуванию "непригодности 1с".
"Думаю, она будет востребована." - нет, ты ошибаешься.
прим.: и - да, у меня высшее образование по специальности, так, на всякий случай - а то ты к этому даже начал было апеллировать...

(71) Но видно плохо ты учился раз 1С - ом занимаешься ))))

(72): ой какой лакмусовый комментарий у тебя получился...

(72) О, мсье тролль, расходимся :)

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

(75) Да какбе ты тут немношк обосрамшись. Решение было озвучено гораздо до 75-го камента. Но ты не пиши уже, да.

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

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

(78) я-бы добавил, что уже отчитался, что все работает шустро и красиво (за полдня), интересно услышать об нагрузочном тестировании на основании которого был сделан вывод "все хорошо".

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

(78) Да забей :)