Перешли сегодня на 8.3.15.1700 и PG 10.10.
До этого гоняли на тестовой базе - все путем работало.
Сейчас когда зашли все пользователи, стало периодически выкидывать пользователей с сообщением:
"Ошибка выполнения запроса
Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call:
по причине:
На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто"

Выкидывает из всех конфигураций и свежих ЕРП и древних УПП.
Че это за такое и как с этим бороться? Может у кого было такое.

Сейчас выяснилось, что ресурс у всех разный. Т.е. вообще в разнобой. Как то может быть связано с кэшем серверным или чем то подобным?

какая то срочная необходимость  в 8.3.15  вообще есть ?

(2) Просто сидели на 8.3.13, а новые конфиги уже рекомендуют 8.3.14. Посмотрели ошибки, что в 8.3.14 что в 8.3.15 одинаковые, решили на последний переходить. Тем более что есть отзывы, что он быстрее.

Ну и описанное в (0), судя по тому что пишут в инете, происходит буквально на чуть не на всех релизах начиная с 8.3.5. Так что надо понять что за проблема и как ее решать.

(0) Вчера вышел очередной релиз. Идите дальше.

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

(2) Тоже перешли на 8.3.15, ибо
"Рекомендуется использовать текущую версию конфигурации "Управление торговлей", редакция 11 с версией системы 1С:Предприятие 8 8.3.15.1489 (и выше)."
Всё виндовое, MS SQL Server.
После установки платформы 8.3.15.1565 стали возникать периодические вылеты КАМИНа (после ТиИ получше стало, но совсем не исчезло).
А вчера попробовал запустить УТ в толстом клиенте (обычно в тонком работает): постоянные вылеты.
Может, совпадение, но похоже, что дело в толстом клиенте - КАМИН как раз использует толстый клиент. В тонком таких проблем нет.

(7) У нас похоже наоборот. Щас всех заставили ходить под толстым клиентом и уже полтора часа все норм. ТЖ запустил, логи смотрю, пока никакого криминала, но пока и не рушится ничего.

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

Для статистики.
В течение недели поменял платформу 8.3.15.1700 (Две PG, одна MSQL)
Полёт нормальный

Хм, почти два часа все было норм, щас опять выкинуло, причем не всех. Может старые конфиги УПП и КА мешают современной ЕРП? Фигово что все на одном РПХосте сидит. Так можно было бы локализовать хоть на предмет какая база выглючивает.

Может в лицензии ПРОФ есть ограничение на количество соединений/сеансов? У нас в сумме свыше 256 точно бывает, если считать фоновые и вообще все.

(0) ктож одновременно меняет платформу и субд?

(12) чисти настройки кластера и заново настраивай

ТС, не гонитесь за хотелками типовых. Типовая хочет, а платформа не может. Вот как бывает оказывается.
В смысле последние релизы (13-14-15) платформ баговатые идут. И конца и края не видно.
Откатитесь на тот релиз платформы где работало. В крайнем случае поставите отдельно службу 15ю для одной базы, а остальные будут жить спокойно.

(11) Запустите несколько агентов на разных портах.

Для начала почистить кэш на сервере.
Скрипт с 1С-овского ИТС.
Остановка службы 1С:Предприятие с очисткой временных файлов. (естественно подставить свои пути к кластеру, и имена служб).


set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="C:\Windows\Temp"
echo stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%


Если баз не много (3-5), то установить в настройках рабочего сервера 1 базу на процесс.
Хотя для начала я бы попробовал наоборот - типовые настройки.
Очень странно, что при 256 сеансах у вас один rphost.
Проверьте - нет ли ограничений по памяти.
Включить ТЖ, анализировать логи падающих процессов.

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

(13) Мы. Просто появилась возможность сделать все и сразу. Изначально стояла задача перейти на PG, а так как PG хочет не менее 14-ой, то решили не мелочиться и ставить сразу 15-ую. Естественно тестили это дело. (15) Ну 13-ая у нас пока висит, на всякий случай. (16) Тоже вариант, но щас пока смотрим как оно работает без извращений. Есть еще мнение что не почистили кэш, но админы уверяли что почистили, потому что щас выкинуло только двух пользователей, остальные работают.

(17) Кэш на сервере почистился, ибо базы полностью пересоздавали когда со скуля на PG переводили. Т.е. в оснастке удалялись и создавались заново, по крайней мере со слов админов. :)

(17) "Если баз не много (3-5), то установить в настройках рабочего сервера 1 базу на процесс.
Хотя для начала я бы попробовал наоборот - типовые настройки.
Очень странно, что при 256 сеансах у вас один rphost. " Для этого надо иметь лицензию КОРП, а тут только ПРОФ.

Вдогонку к (7).
Ну вот, выходит новая конфа Торговли (ничего принципиально нового, только ошибки исправили), и вот на тебе, рекомендуют ещё более новую платформу, чем предыдущая версия конфы:
"Рекомендуется использовать текущую версию конфигурации "Управление торговлей", редакция 11 с версией системы 1С:Предприятие 8 8.3.15.1656 (и выше)."
Если совсем плохо будет, придётся как-то организовывать возможность работы двух платформ для разных БД. Раньше с таким не сталкивался.

(10) А какие конфигурации, если не секрет?

Хм. Убрали ключ -debug все заработало. Я понимаю что этот ключик зло на рабочей базе, но должно же и с ним работать. Может че с окружением не так.

(23) у вас там что, круглосуточная работа?

(23)И да, вы чистку с отменой отладки не совместили?

*чистку кэша

(25) Я вчера вечером, всех выгнал, почистил все кэши. Не помогло. Отключил отладку на сервере. Помогло. На ночь поставил закрытие месяца. Не вылетело до сих пор и пока никого за полтора часа работы не выкинуло. Но в логах много событий типа:
"00:31.881002-0,EXCP,0,process=rphost,OSThread=5664,ClientID=6802,Exception=NetDataExchangeException,Descr='server_addr=(2)192.168.3.32:59976 descr=2(0x00000002): Не удается найти указанный файл.  line=1149 file=src\DataExchangeServerImpl.cpp'"
и
"00:26.084004-0,EXCP,3,process=rphost,p:processName=ERP_SINAR,OSThread=8140,t:clientID=125,t:applicationName=BackgroundJob,t:computerName=1CSA,t:connectID=3800,SessionID=1267,Usr=Жмаева Л.Д.,Exception=SeanceContextException,Descr='Сеанс отсутствует или удален
ID=4828417a-f23b-4e5b-8c3f-f9dd08327b56, File=src\ClusterDistribImpl.cpp(1640)'"
Хотя пользователи ни на что не жалуются. Твои тезки периодически завершаются и появляются новые вместо них. :)

А вообще ЕРП на 8.3.15 и PG довольно быстро работает, по сравнению с 8.3.13 и MSSQL 2005, при прочих равных (оборудование и ОС остались теми же).

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

(27) "Отключил отладку на сервере. Помогло. "
А включать отладчик по http пробовали? Просто интересно.

(30) +1

(30) Нет. Не пробовали.

(29) А че конкретно надо регулярно запускать для обслуживания?

(33) vacuum analize - дабы похерить старые версии и обновить статистику.

+ (34) автовакуум не всегда отрабатывает...

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

(36)говорят стало лучше, самому некогда пощупать - работы просто пипец... вото ветка где спецов по постгри есть: Какую версию PostgreSQL ставить?

Все равно выкидывает. Значительно реже и не в таких масштабах (меня с двух разных баз выкинуло по одному разу за 4 часа), но выкидывает. Щас есть два мнения: 1. Что то с сетью или сетевыми интерфейсами. 2. На новой платформе могут работать только новые конфиги и надо убирать все старые на старую платформу.

+(38) При этом закрытие месяца работало всю ночь и еще потом два часа днем и доработало до конца без ошибок. Т.е. проблемы начались когда подтянулись пользователи. Буду пробовать добиваться чтобы все старые конфиги убрали с новой платформы.

Писал уже в (6) проверьте процессы они перезапускаются ? если да проверьте логи скорее всего отваливается лицензия следовательно падает процесс который не сразу перезапускается ибо лицензия глюкнула, если конфа работает под толстым клиентом то это 100% вылет пользователя если под тонким может и незаметно пройти если падение не долгое было.

(40) естественно чтобы посмотреть логи необходимо настроить технологический журнал.

(40) Да, процессы перезапускаются. Причем активно. Хотя меньше чем вчера. (41) Настроил ТЖ, но в этом потоке сообщений про лицензию не вижу ничего. Какую надо включить настройку и по какому признаку потом искать именно эти записи?

(20) >> Для этого надо иметь лицензию КОРП, а тут только ПРОФ.

А в ПРОФ эти параметры вообще закрыты для изменения или не принимаются изменения?
Я думал, что в целях эксперимента эти параметры менять всё таки можно.

(40) Выкидывает не всех и не изо всех баз. Т.е. как-то выборочно.

(43) Менять можно. Но при входе очередного пользователя ругается что параметры надо задать по умолчанию.

(44) >> Выкидывает ... выборочно.

Пробовали чистить локальный кэш у этих самых выборочных пользователей?

(42) если есть возможность поставь атрибут "ALL" (возможны тормоза) чтобы всвё видеть или "SRVC" чтобы посмотреть что с сервисами происходит

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

запусти пинг на долго... потом когда стопнешь через часик - посмотри % потерь. Насколько помню >0,05% - уже очень плохо

(49) Тогда лучше уж писать результаты пинга в файл txt.  И потом анализировать.

(46) Это первое что сделали. Меня тоже выкинуло.

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

Но вообще сомнительно, что проблемы сети вылезли одновременно со сменой СУБД и платформы.

(49) Пинг с какой машины и до какой?

(52) Ну если что, то можем быстро переползти обратно на 8.3.13. Щас пока работаем. Но думаю что в итоге так и поступим.

(53) От клиента к серверу. На машине проблемного пользователя ping SERVER1C....

(45) не очередного, а примерно после 10-го пользователя.

А по умолчанию там указано 128 сеансов на один рпхост. Так что наличие только одного рпхоста при таком числе пользователей уже повод насторожиться.

И не можешь подсказать, на какой типовой уже нужно релиз платформы 8.3.14+ ?

(54) Я бы на 8.3.13 не рисковал, точнее говоря, успешно его пропустили и сели на 8.3.14.1779
В сентябре вернули параметры на дефолтные и продолжаем пока сидеть на нем.

(56) Нужно ни на какой, а рекомендуется уже на последней ЕРП. Ну и с PG 10.10 тоже рекомендуется уже 8.3.14, хотя еще пару недель назад было 8.3.15, потом поменяли почему то, может именно по этому.

(57) Если на 8.3.14, то это снова на неделю минимум подготовка, чтобы у всех ее установить.

(53) с на какой валится до сервера 1С, если серверов несколько - до каждого из них.

(52) Точно -l 60000? У меня при таком параметры 100% потери пакетов.

(55) Нет проблемного пользователя. Всех с разной периодичностью выкидывает.

(58) >> пару недель назад было 8.3.15, потом поменяли почему то, может именно по этому.

Нет. Не поэтому.
Во-первых, там указано НЕ НИЖЕ(!!!) 8.3.14.
Во-вторых, есть процедура тестирования СУБД для работы с каждой версией платформы. Только когда весь протокол успешно соблюдён публикуют информацию о требованиях по совместимости.
Если бы была проблема с 8.3.15, об этом написали бы в файлике об особенностях СУБД.

(63) не ниже 8.3.12 вроде. Чего вы нас путаете? Это рекомендованная 8.3.14, это разные вещи, неи ниже и рекомендованная.

(61) Да. /l 60000. Потери могут быть но незначительные.
Можешь попробовать с меньшими значениями. Например, с 1000.

(64) Никто никого не путает. Я писал на сообщение автора ветки в (58) о версии СУБД PG 10.10.
Она (PG 10.10) работает с платформой НЕ НИЖЕ 8.3.14. То есть вполне совместима с 8.3.15.
При откате на 8.3.13 использование PG 10.10 на свой страх и риск. Вроде как, должно работать, но это не точно и 1С это не проверяла.

(61) Ну значит у вас стоит оборудование которое не тянет. коммутаторы/свитчи не все тянут или игнорируют больше заявленного размера.

ОФФ. Вообще странно, что сплошь и рядом встречается игнорирование требований совместимости со стороны пользователей и непонимание того, чем отличается "необходимо" от "рекомендуется" и требования к конфигурации и к СУБД.

(61) У вас сеть точно проводная, не WiFi?
Проверьте маршрутизацию. Через сколько коммутаторов проходят пакеты. Может админы что-то накосячили или действительно какой-нибудь коммутатор глючит или накрылся вовсе.

PostgreSQL, версия 10.10-1.1C

Внимание! Текущая версия PostgreSQL предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.14.1565

(69) Или выяснится что петля в сетке и как только нагрузка на локалку слега вырастает ("когда зашли все пользователи") сетевой шторм начинается ))

Админам скажи чтоб iPerf -ом проверили  и в НЕ рабочее время. А то всю локаль положат.

(36) https://forum.infostart.ru/forum86/topic229257/#message2327174
В 7-ом сообщении текст запроса на 1С и его трансляция в PostgreSQL.
Не думаю, что довели оптимизатор до такого состояния, чтобы он с легкостью работал с подобным. Жаль, что нет плана этого запроса.

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

(65) /l 60000 - 100% потерь во все стороны, /l 6000 - норм. Уверен, что нолями не ошибся? Проблем с сетью, с 1С нет.

(71) от петли обычно в итоге сеть ложится

(75) Уверен. Нолями не ошибся. 60000 - это максимально возможный размер буфера (точнее - 65536).
Насколько большими пакетами обменивается 1С - я не знаю. Вполне возможно, что и 1000 достаточно.
У меня с 60000 потерь нет.

(77) Даже при /l 20000 - потери: 50%

(78) То что потери при больших пакетах это еще ничего не говорит.

(77) Между сервером 1С и сервером PG ставил 60000 - норм. Между моим компом и сервером 1С 100% потери, может из-за того что 100Мб сеть или куча всякого между нами. Но до перехода на 8.3.15 все же работало. Что интересно оно и на тестовом сервере, в котором пользователи на корпии базы всякое крутили, все работало норм.

(80) а у вас там до кучи админы что-то перепилить не решились пока вы платформу и базовод не апнули?

(0) В 8.3.15 при обновлении агрегатов оборотного регистра накопления падает rphost.exe
Во всех типовых современных типовых есть такое регзадание, которое пытается выполниться, валит rphost, менеджер создает новый, перекидывает туда сеансы и рег задание, рег задание пытается исправить свою ошибку и выполниться вновь, валит rphost.....

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

https://bugboard.v8.1c.ru/error/000057789

(82) Спасибо, попробуем.

Регл. задание Обновление агрегатов отключено. Агрегатами вообще не дает никак управлять. Т.е. погашены закладки и кнопки касающиеся агрегатов.

(82)ээээ, если корп и серверов есть - все фоновые можно подальше засунуть.
И да, теоретически пересчитывать можно средствами постгри, но нужно скрипт запилить.

Что то совсем все плохо. Щас при проведении документов начало ругаться что объект не найден. Все встало колом. PG жрет процессор под 100%, при этом все висит. Какой-то так себе опыт перевода на PG получается. :)

Или мы не умеем ее готовить или ERP 150Г и 150 пользователей в принципе не способна работать на PG.

(87) В БГУ 1.0 на PostgreSQL 10.10 проведение одного из документов(внутреннее перемещение) может приводить к такому же эффекту, причем еще занимается вся доступная память, включая своп, после чего процесс postgres самоубивается с криками "Out of memory!" и всех выкидывает.
enable_nsetloop=off не помогает.
На 9.6.7 и 11.5 такого происходит.

К (89) Такого не происходит.

А "объект не найден" больше похоже на платформу, чем на СУБД. Может, совокупность версий конфигурации и платформы.

(91) Может. Просто чем дальше тем хуже. Возможно с индексами проблема, хотя делали реиндекс базе. Щас наверное откатим на MS SQL, а на копии посмотрим че это за фигня. Проблема конкретного документа или с базой чета. Тут вообще все странно, отражение в регл. учете запускается, в регистре к отражению все документов 30, но он часами не может их отразить, фоновое задание висит и только в размерах пухнет.

Хм. Короче. Выяснилось что упирается в дисковую подсистему. Длинная очередь к диску. Даже крутой рейд 10 не помогает. Поставили базу на SSD 970 EVO PLUS - все начало летать, право пока только половина пользователей ее нагружают, но раньше все висело даже на меньшем количестве. PG любит быстрые диски. Ну таки SDD даже если каждый год менять, то это все-равно дешевле, чем покупать новый MS SQL, раз так в 50. :) Щас вот думаем, таки в продакт завести SSD или воспользоваться вредными советами и отключить fsync и прочее, ибо типа на рейде есть батарейка и не страшно.

(93) А включить асинхронную запись в постгресе пробовали?

(94) Нет пока. Админы тут посмотрели статистику и выяснили что просела производительность дисков. Короче, расследование показало очевидную вещь. У PG куча мелких файлов и он в процессе работы еще не меньшую кучу создает. Т.е. нужен быстрый произвольный доступ, что SSD конечно предоставляет с легкостью, а массив на SAS, пусть даже серверных дисках, не может. Отсюда же понимание почему у MS SQL не было таких проблем - там два больших файла на базу и еще несколько служебных и нужно быстрое последовательное чтение, что конечно уже рейд легко дает. Так что пока ситуёвина такая: если хотите переходить на PG да еще с большими и нагруженными базами, то нужны SSD или какие-то другие массивы с большой скоростью произвольного доступа.

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

+(96) "по сети" читать как "по сути")

(93) На RAID контроллере с кэшем и батарейкой и(тем более) SSD влияние fsync почти не заметно, можно даже full_page_writes включить для большей безопасности.
Еще PostgreSQL любит, чтобы вся база(или большаяя ее часть) была в shsred buffers, а shared buffers можно поместить  в huge pages, huge page сделать размером в 1ГБ..
Еще всем процессам PostgrSQL(autovacuum, сборщик статистики, bgwriter) нужны незанятые ядра, чтобы не тормозить.

Поставили SSD
Пользователи стали более лучше и быстрее переключаться с упавшего rphost-а :-)
profit

(99) Ну это да, это косяк платформы. :) Будем переходить на 8.3.16, там в последнем вроде как раз эти косяки с падением процессов пофиксили. Но вообще это конечно засада. После 8.3.12 ни одного стабильного релиза. Они бы вместо всяких, мало кому нужных, рюшечек довели бы до ума платформу, чтобы она тупо не падала от любого чиха. А то похоже на продукцию АвтоВАЗа еще лет 10 назад, когда в рассыпающемся ведре с болтами кучу всяких наворотов, которые тоже через раз работают.

Так, ну что, проблемы все победили. Щас напишу как. Сначала напомню некоторые вводные по ПО. Платформа 8.3.15.1700, PG 10.10, ERP 2.4.9.98, более 150 активных пользователей.
1. Сначала победили дикие тормоза PG. Конечно всяко настраивали по всем рекомендациям, но это не помогало. Как выяснилось, эта СУБД хранит все в куче мелких файлов, что закономерно требует быстрого произвольного доступа. Проблема была решена установкой базы на SSD Samsung 970 Pro 1Tb, через плату прямо в слот PCI-E. Щас делаем ставки на сколько его хватит.
2. Выкидывание пользователей было побеждено заменой общего макета КомпонентаПечатиШтрихкодов на версию от последней БСП. Такую рекомендацию много где видел и она помогла.
3. В процессе решения проблем научились пользоваться ТЖ и с его помощью выловили и поправили кучу собственных косяков, о которых даже не подозревали.

(101) Итого месяц работы нескольких высокооплачиваемых специалистов и расходы на новое железо.
MSSQL дешевле бы обошёлся.

(102) Нет, не обошелся бы он дешевле. Там насчитали больше ляма на обновление скуля. За месяц на ЗП и диск потратили пару сотен тысяч.

(102) Ну и половину времени потратили на разбор с вылетом 1С, что к скулю вообще не имеет никакого отношения. Опять же потратили не месяц, а две с половиной недели и конечно не все это время специалисты занимались проблемой. Плюс положительный эффект от того что специалисты стали еще более специалистами. Так что думаю что сумму можно еще на два делить смело. :)

(101) " побеждено заменой общего макета КомпонентаПечатиШтрихкодов"

так и знал.

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

Пузану - респект! Что победил и не поленился описать\отписаться. Реально уважаю за такое отношение. Желаю всяческих успехов, молодцы!

(106) Зачем ежетригоднро покупать лицензии? Они что, протухают?

(104) Теперь вам либо привязать их цепью к батарее, либо ловить где то в границах МСК,

(101) Скажите, а из какой версии БСП вы брали этот общий макет? В версиях 3.1.2.252 и 3.0.3.164 не нашел...

(110) Из БПО 2.1.2.5

(27) Exception=SeanceContextException,Descr='Сеанс отсутствует или удален - эту проблему не вылечили?