22.12.2020 09:45 ! Важно
Уважаемые пользователи! При использовании платформы версии 8.3.18.1208 могут наблюдаться серьезные замедления работы программы. В очередном выпуске платформы 8.3.18 эта проблема будет устранена, а пока используйте версию 8.3.16.1814 или 8.3.17.1851. Приносим извинения за доставленные неудобства.
Нет ну не отморозки. Я только вчера накатил новый релиз. Думал релиз выпущен 19.11.20 уже месяц как можно ставить. И тут на тебе откатывай на 17, а лучше на 16.
1С ты зачем так клепаешь релизы? Где контроль качества ? Где тестирование ? Что вы вообще там с 19.11.20 делали премию обмывали за ускоренные темпы выпуска г... на ?
Уважаемые пользователи! При использовании платформы версии 8.3.18.1208 могут наблюдаться серьезные замедления работы программы. В очередном выпуске платформы 8.3.18 эта проблема будет устранена, а пока используйте версию 8.3.16.1814 или 8.3.17.1851. Приносим извинения за доставленные неудобства.
Нет ну не отморозки. Я только вчера накатил новый релиз. Думал релиз выпущен 19.11.20 уже месяц как можно ставить. И тут на тебе откатывай на 17, а лучше на 16.
1С ты зачем так клепаешь релизы? Где контроль качества ? Где тестирование ? Что вы вообще там с 19.11.20 делали премию обмывали за ускоренные темпы выпуска г... на ?
По теме из базы знаний
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Выскажу не популярное мнение.
Ответственность за работоспособность ИС лежит на том, кто эксплуатирует (внедряет) эти ИС. Не на вендоре.
Если работа ИС важна и критична, необходимо все сначала протестировать на своей инфраструктуре и своих бизнес-кейсах и только потом обновлять. Обновление без тестов - риск НЕ вендора, а того, кто обновляет.
Иногда дешевле обновить, "словить баг" и откатить, чем тратить время и деньги на тесты. Тогда эти риски должны быть заложены в процесс, обговорены с ответственными лицами со стороны бизнеса и уж точно не должны быть "сюрпризом".
ЗЫ Да, вендор косячит (сюрприз-сюрприз), а есть кто-то, кто всегда и всё делает без ошибок и ни разу не косякнул? Себя любимого прощаем (ну я же не специально, да и обстоятельства со сроками и дурацким ТЗ..), а все другие - отморозки.. удобненько))
Ответственность за работоспособность ИС лежит на том, кто эксплуатирует (внедряет) эти ИС. Не на вендоре.
Если работа ИС важна и критична, необходимо все сначала протестировать на своей инфраструктуре и своих бизнес-кейсах и только потом обновлять. Обновление без тестов - риск НЕ вендора, а того, кто обновляет.
Иногда дешевле обновить, "словить баг" и откатить, чем тратить время и деньги на тесты. Тогда эти риски должны быть заложены в процесс, обговорены с ответственными лицами со стороны бизнеса и уж точно не должны быть "сюрпризом".
ЗЫ Да, вендор косячит (сюрприз-сюрприз), а есть кто-то, кто всегда и всё делает без ошибок и ни разу не косякнул? Себя любимого прощаем (ну я же не специально, да и обстоятельства со сроками и дурацким ТЗ..), а все другие - отморозки.. удобненько))
(103) Технический специалист не сможет смоделировать реальную работу бухгалтеров и расчетчиков за разумное время. И уж тем более групповую работу множества пользователей. Так что это мнение потому и непопулярно, ибо невыполнимо и утопично.
(105) всегда есть путь "Правильный" и "Быстрый". Разработать сценарий тестирования вполне реализуемая задача, хоть и долгая и затратная. Что тут сложного? У бухгалтеров и расчетчиков все строго регламентировано - "открываю тут, жму там, запускаю это..". И сценарий этот может пригодиться и для следующего обновления.
Как минимум надо посчитать и предложить бизнесу - риски простоя либо столько то денег. Бизнес сам может подумать, что для него выгоднее.
Чаще всего регл.учет не такой требовательный к непрерывности работы и может подождать пол дня отката платформы (с учетом времени на попытки что-то исправить и попробовать вылечить, обычно целый рабочий день проходит "черт знает как").
А вот если от работы системы зависит как быстро вы отпустите клиента на кассе - совсем другой уровень рисков и тут можно [и нужно] потратить побольше денег, но обеспечить обновление без проблем.
Как минимум надо посчитать и предложить бизнесу - риски простоя либо столько то денег. Бизнес сам может подумать, что для него выгоднее.
Чаще всего регл.учет не такой требовательный к непрерывности работы и может подождать пол дня отката платформы (с учетом времени на попытки что-то исправить и попробовать вылечить, обычно целый рабочий день проходит "черт знает как").
А вот если от работы системы зависит как быстро вы отпустите клиента на кассе - совсем другой уровень рисков и тут можно [и нужно] потратить побольше денег, но обеспечить обновление без проблем.
Прошло почти полгода. Был выпущен релиз 18.1363, который, по-моему, ещё более тормозной. Я даже скажу в чём причина подвисаний. В рандомно запускающейся службе UpdateConfigurationLicense. Во время её работы базу клинит наглухо у всех (клиент-сервер). 1С прислал разъяснения, мол, запускается единожды, и только после обновления конфы. Угу, ага. Только под одним пользователем может за час раз раз 10 запуститься. Отсюда висяки и тормоза. Началось с 18.1208. Курю тему даунгрейда клиент-сервера (самописка), а чувствительных к законодательству решений (бух, зуп) перевожу на файловый вариант, пусть там тормозят в гордом одиночестве.
8.3.18.1433
Не работает ConnectAgent, простая попытка вызвать данную функцию вызывает Access Violation
Вот например такой код:
Приводит вот к чему:
И вот что в логах винды:
Подобные пробелмы описаны так же и
Если у кого будут предложение по решению данной проблемы (кроме смены версии платформы), готов закинуть вознаграждение.
Не работает ConnectAgent, простая попытка вызвать данную функцию вызывает Access Violation
Вот например такой код:
$connector = New-Object -ComObject "V83.COMConnector"
$AgentConnection = $Connector.ConnectAgent($server)
Write-Host "SUCCESS!!!"Приводит вот к чему:
И вот что в логах винды:
Имя журнала: Application
Источник: Application Error
Дата: 19.08.2021 23:45:04
Код события: 1000
Категория задачи:(100)
Уровень: Ошибка
Ключевые слова:Классический
Пользователь: Н/Д
Компьютер: ----------------------------------------
Описание:
Имя сбойного приложения: powershell.exe, версия: 10.0.14393.206, метка времени: 0x57daccf5
Имя сбойного модуля: rtrsrvc.dll, версия: 8.3.18.1483, метка времени: 0x60a3189b
Код исключения: 0xc0000005
Смещение ошибки: 0x000000000004c4df
Идентификатор сбойного процесса: 0x11d0
Время запуска сбойного приложения: 0x01d7953b15620fe8
Путь сбойного приложения: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Путь сбойного модуля: C:\Program Files\1cv8\8.3.18.1483\bin\rtrsrvc.dll
Идентификатор отчета: 7c599cd6-90db-4d7c-8e21-19efd24399e6
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом: ПоказатьПодобные пробелмы описаны так же и
Если у кого будут предложение по решению данной проблемы (кроме смены версии платформы), готов закинуть вознаграждение.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот