Платформе 8.3 уже больше 2 лет... с 03.07.2012. Наконец решились обновиться... Релиз 8.3.5.1119 300+ пользователей... Стольких "ярких картинок" я давно не видел... Это не говоря уже о том что "требования назначения функицональности" и "Отказоустойчивый кластер" просто не работают...
Здесь и "Отсутствующие сеансы" и "Ошибка совместного доступа к файлу" и падения рабочих процессов, и тех лог 20 ГБ ошибок за 10 минут... и "Ошибка блокировки", и "Соединение не удерживается"... И падение клиента и падение конфигуратора.. За неделю узнали всё. Это в самой простой конфигурации. 1 центральный сервер и 2 рабочих, без отказоустойчивости, и с настройками чтобы везде был один рабочий процесс.
А у всех так было? Кто какую версию использует? За 2 года эти ошибки так и остались? или были какие-то "Удачные" версии? Кто-нить не подскажет какие?
8.3.12.1469 новый прикол.
Думаю многие видели внешнюю обработку печати ТТН, у нее есть три вкладки.
Последние две вкладки содержат на себе табличные документы, с кучей накиданных в них элементов управления.
Решение спорное, но не суть.
Что мы видим в 8.3.10 см вложение. Все красиво, все показывается.
А вот на платформе 8.3.12 см. вложение, ваще труба, элементы управления вроде и есть, но они невидимки, неотрисовываются чуть более чем полностью...
8.3.12.1469 УПП 1.3.107.1. Режим совместимости 8.2.13
1. Перестает работать прокрутка мышкой в отчетах, если изменять размер окна при помощи кнопок "Развернуть", "Восстановить". К примеру в отчете "Оборотно-сальдовая ведомость".
2. Вылетает платформа при открытии окна настроек интерфейса пользователя "Настройка главного меню" и попытке перейти на вкладку "Команды".
3. Что-то сломали в работе свойства формы "ТекущийЭлемент". До недавнего времени прекрасно работающий код пришлось заколхозить.
Процедура ШтрихГрузаПриИзменении(Элемент)
Если Не ПустаяСтрока(ШтрихГруза) Тогда
// ТУТ ЧТО-ТО ДЕЛАЕТСЯ ВАЖНОЕ
ШтрихГруза = "";
ТекущийЭлемент = ЭлементыФормы.ТабРекламаций; // Фелькер И.В. Нужно сначала сделать так из-за косяка платформы 8.3.12 не дает вернуть фокус на это же поле ввода
ТекущийЭлемент = ЭлементыФормы.ШтрихГруза;
КонецЕсли;
КонецПроцедуры
Показать
Это в рабочем месте на ТСД реализовано, сканируют штрихкод в поле ввода.
По идее после сканирования штрихкода мы должны остаться в этом же поле ввода, но в 8.3.12 поведение сломалось.
Ловим стабильный глюк платформы при попытке накатить обновление на базу данных. 8.3.12.14.69, 8.3.13.1198
База данных из коробки имела режим совместимости 8.3.10, мы ее перевели в 8.3.12 чтобы можно было использовать расширения со всеми возможностями платформы 8.3.12. Расширение пилилось, изменения в базе применялись, все вроде красиво, однако пришло время обновить релиз конфигурации и вот понеслось.
Лезет ошибка такого плана.
Ссылочная константа содержит недопустимый ссылочный номер таблицы
67061:00000000000000000000000000000000'
Начинаем раскопки, врубили технологический журнал и давай смотреть, где там конфигуратор матюкается, а матюкается он на вот этом запросе:
30:28.358042-3,EXCPCNTX,3,SrcName=SDBL,process=1cv8,OSThread=7468,Usr=ФелькерИВ,Trans=0,Sdbl='INS ERT REF IN TO Reference286
(ID,Marked,PredefinedID,ParentID,Folder,Code,Description,Fld9330,Fld9318,Fld9319,Fld9320,Fld9321,Fld9322,Fld9323,Fld9324,Fld9325,Fld9326,Fld9327,Fld9328,Fld9329,Fld9348,Fld9317,Fld9332,Fld9333,Fld9334,Fld9335,Fld9336,Fld9337,Fld9338,Fld9339,Fld9340,Fld9341,Fld9342,Fld9343,Fld9344,Fld9345,Fld9346,Fld9347,Fld9331,Fld9349,Fld9350,Fld9351,Fld9352,Fld9353,Fld9354,Fld9355,Fld9356,Fld9357,Fld9358,Fld9359,Fld9360,Fld9361,Fld9362,Fld9363,Fld9364,Fld9365,Fld9366,Fld9367,Fld9368,Fld9369,Fld9370,Fld9371,Fld9372,Fld9373,Fld9374,Fld9375,Fld9376,Fld9377,Fld9378,Fld9379,Fld9380,Fld9381,Fld9382,Fld9383,Fld9384,Fld9385,Fld9386,Fld9387,Fld9388,Fld9389,Fld9390,Fld9391,Fld9392,Fld9393,Fld9394,Fld9395,Fld9396,Fld9397,Fld9398,Fld9399,Fld9400,Fld9401,Fld9402,Fld9403,Fld9404,Fld9405,Fld67053,Fld67109,Fld67110,Fld67059,Fld2104,VT9406.(LineNo9407,Fld9408,Fld9409,Fld9410),VT9412.(LineNo9413,Fld9414,Fld9415,Fld9416,Fld9417))
VALUES (
SEL ECT ID,Marked,PredefinedID,ParentID,Folder,Code,Description,Fld9330,Fld9318,Fld9319,Fld9320,Fld9321,Fld9322,Fld9323,Fld9324,Fld9325,Fld9326,Fld9327,Fld9328,Fld9329,Fld9348,Fld9317,Fld9332,Fld9333,Fld9334,Fld9335,Fld9336,Fld9337,Fld9338,Fld9339,Fld9340,Fld9341,Fld9342,Fld9343,Fld9344,Fld9345,Fld9346,Fld9347,Fld9331,Fld9349,Fld9350,Fld9351,Fld9352,Fld9353,Fld9354,Fld9355,Fld9356,Fld9357,Fld9358,Fld9359,Fld9360,Fld9361,Fld9362,Fld9363,Fld9364,Fld9365,Fld9366,Fld9367,Fld9368,Fld9369,Fld9370,Fld9371,Fld9372,Fld9373,Fld9374,Fld9375,Fld9376,Fld9377,Fld9378,Fld9379,Fld9380,Fld9381,Fld9382,Fld9383,Fld9384,Fld9385,Fld9386,Fld9387,Fld9388,Fld9389,Fld9390,Fld9391,Fld9392,Fld9393,Fld9394,Fld9395,Fld9396,Fld9397,Fld9398,Fld9399,Fld9400,Fld9401,Fld9402,Fld9403,Fld9404,Fld9405,Fld67053,CASE WHEN Folder THEN 67061$00000000000000000000000000000000 END,CASE WHEN Folder THEN 67062$00000000000000000000000000000000 END,Fld67059,Fld2104,VT9406.(LineNo9407,Fld9408,Fld9409,Fld9410),VT9412.(LineNo9413,Fld9414,Fld9415,Fld9416,Fld9417)
FROM Reference286
)'
Изучение структуры ИБ до ее обновления показывает, что Reference286 это справочник номенклатуры (см. вложение структура).
Из расширений в номенклатуре создается только один реквизит "Алмаз_НеПроизводится".
И в этом справочнике нет полей Fld67109, Fld67110 до обновления, в которые нужно вставить значения CASE WHEN Folder THEN 67061$00000000000000000000000000000000 END, CASE WHEN Folder THEN 67062$00000000000000000000000000000000 END.
Роем дальше, что это за поля, сверяем конфу ИБ и новую конфу поставщика и видим, что в справочник добавлено два реквизита КодОКВЭД2, КодОКПД2. (см. вложение сравнение конфигураций)
И что получается при реструктуризации базы данных конфигуратор некорректно отрабатывает ситуацию добавления в конфигурацию двух новых справочников.
Если на базе запустить ТИИ, то в процессе получим ошибку
Ошибка SQDL
Таблица или поле Fld2104 не содержится в разделе FR OM (pos=7)
Возвращаемся к вложению со структурой справочника и видим что это поле находится именно в нем и оно называется "ОбластьДанныхОсновныеДанные" и имеет тип "ОбщийРеквизит.ОбластьДанныхОсновныеДанные".
(1893) Воспроизвел ошибку на пустой базе данных, если кому интересно, то он может взять базу из вложения и попытаться применить изменения конфигурации.
Общий порядок воспроизведения ошибки такой:
В новой пустой конфигурации создаем одну подсистему и одну роль.
Роль назначаем как основную.
Потом создаем справочник с любым наименованием.
Создаем в нем допустим 4 реквизита ничего не меняя вообще, ни имен, ни тип данных, вообще ничего.
Включаем справочник в подсистему и даем на него все права в нашей ранее созданной роли.
Применяем изменения! Потом создаем новое расширение, название не играет роли. Назначение у расширения выбираем "Дополнение". Снимаем на всякий случай галки "Безопасный режим", "Защита от опасных действий".
Наследуем/добавляем в расширение справочник ранее созданный в основной конфигурации.
Создаем в расширении в справочнике новый реквизит, тоже ничего не меняем в нем.
Применяем изменения! Теперь в основной конфигурации создаем еще один справочник, и несколько произвольных реквизитов по желанию.
Даем на него все права в нашей роли и включаем в подсистему
Потом в первом справочнике в основной конфигурации добавляем еще один реквизит и указываем в качестве типа данных второй справочник.
Применяем изменения! Получаем выше обозначенную ошибку.
(1897) Сам виноват. Нафига ты вообще упоминал другую версию? На первую линию суппорта не садят людей, отягощенных интеллектом и получающих плюшки за работу с клиентами. Такие люди стоят других денег. А у этих другая задача. Это та же роботизированная сортировка писем, только еще дешевле. Плюшки они получают за скорость сортировки, поэтому нельзя оставлять им шанса на формальную отписку. Их гораздо сильнее дрюкнут за пропуск на разрабов "левой" заявки, чем за "заворот" нормальной. Время программистов стоит дорого.
(1897) Да, актуальная. Но эта же ошибка воспроизводится в 8.3.12.1469, которая не является тестовой. Что по их логике означает, что ошибка не может быть рассмотрена на Testplatform, а только на v8.
(1899) Если так рассуждать, то попав на ошибку в тестовом релизе платформы, я ОБЯЗАН скачать и установить последнюю не тестовую платформу, плипнуть в ту же ошибку и если она есть, то писать не на Testplatform, а если ее нет. то писать на Testplatform. Тем самым я должен сделать за них ихнюю же работу по поиску корней ошибки, появилась ли она ранее или только в последнем тестовом релизе платформы. А ведь ты еще им попробуй доказать, что ошибка есть...
К слову сказать, 8.3.12.1469 сплошной глюкодром и не понятно как она вообще в релиз вышла из вчерашних тестовых...
сидим на 8.3.10.2667, ошибок замечено не было, раньше гонялся за свежими платформами, настрадался, вот теперь фиг поставлю свежую если конфа не попросит
Доброго времени суток!
На релизе 8.3.12.1595 обнаружилась занимательная коллизия: V83.COMConnector даёт неверные порты соединения агента сервера. Он использует только 1540. На других релизах такой проблемы я не наблюдал.
Бух 3.0.65.69 затребовала платформу не ниже 8.3.12.1529.
Хоть вариантов не так и много (пока всего 4: 1529, 1567, 1595, 1616)
во весь рост встает вопрос на какую переходить ((
Сейчас сидим на 8.3.10.2667 - практически беспроблемная.
(1908) однозначно на последнюю и не в коем случае ни на версии ниже или равные 1469 (полно глюков в интерфейсе пользователя, просто глюки и вылеты, проблемы с расширениями наблюдаются)
Начал распространять обновления клиентам, версия 8.3.13.1513. Доменная сеть, установка автоматом из каталога, указанного в DistributiveLocation. У некоторых пользователей наблюдается проблема - установщик не может выгрузить из памяти процесс 1cestart.exe. Приходится делать это вручную, что при наличии более 100 клиентов... ну сами представляете. Причем ситуация одинакова и для юзеров и для админов, но не для всех. Зависимость выявить не смог. Плюс, на некоторых машинах требуется ввод админского пароля для установки Visual C++. Скоро начнем обновлять сервера - отпишусь.
8.3.13.1513 - 6 серверов, нагрузка небольшая - 10 юзеров на один. Только ЗУП ред. 3.1. 2 дня полет нормальный. Основной сервак на 100 пользователей обновлю в выходные.
8.3.13.1513 Неделя полёта, выявленные "особенности":
1. При обновлении больших конфигураций типа Бух КОРП с большим количеством изменений на сравнении периодически рушится конфигуратор.
2. Периодически отваливается отладка на сервере, помогает только перезапуск конфигуратора.
3. Для конфигураций, использующих катрановское лицензирование, требуется установка последней версии клиентской компоненты, иначе глюки с лицензированием.
4. В клиент-серверной архитектуре поломался COM при работе с АДО. Что они там поломали - хз, но пока обнаружено следующее - запрос к LDAP вида <LDAP://DC=d1,DC=d2> перестал работать - автоматически не обнаруживается домен-контроллер, приходится писать так: <LDAP://DCNAME/DC=d1,DC=d2>. На файловых базах - всё ОК, версия (32-64) comcntr.dll значения не имеет.
(1914) Пробовал неоднократно.
Извиняюсь. Платформа к проблеме имеет косвенное отношение. Код в расширении прекрасно работавший на 8.3.10 в новой платформе 8.3.12 стал вызывать падение платформы.
(1913) у нас на ERP в режиме совместимости 8.3.12 на платформе 8.3.12.1469 с применением расширений вносящих новые документы и справочники, наблюдаем такие ошибки при обновлении индексов
Ошибка выполнения процедуры "Обновление индекса ППД":
{ОбщийМодуль.ПолнотекстовыйПоискСервер.Модуль(461)}: Ошибка при вызове метода контекста (ОбновитьИндекс)
ПолнотекстовыйПоиск.ОбновитьИндекс(РазрешитьСлияние, Порциями);
по причине:
Ошибка SDBL:
В схеме базы данных нет таблицы с именем Reference65852
Вот, планируем на последнюю 8.3.12 перейти.
Слава богу, расширений нет. Судя по чейндж-логам в части расширений много правят/фиксят.
Так что судя по всему, расширения нужно аккуратненько тестить перед переходом.
Только что переехали с 8.3.6.2390 на 8.3.12.1685 (windows server 2012 R2 standart)
Вроде пока на удивление гладко. Настройки кластера подтянулись, лицензии не слетели :) Но окончательные выводы делать пока рано.
А, единственное - пришлось дать пользователю 1С в MSSQL 2014 роль сисадмина, чтобы 1С могла какой-то там флаг трассировки включать оптимизационный (валилось при запуске с соответствующей ошибкой). И немного поплясать, чтобы служба стартовала под доменным пользователем. Почему-то при установке не получалось - пришлось устанавливать на дефолтного и менять уже потом в параметрах службы.
Баз много разношерстных, есть и довольно нагруженные. Расширений нет. Есть и MSSQL и postgresql.
Поймал интересное отличие 8.3.12 от 8.3.6 (режим совместимости включен) - на старом релизе в программный обход всех элементов формы не попадали кнопки системных команд, автогенерируемых в командных панелях с автозаполнением (такие как "Записать").
А в 8.3.12 - попадают. Это как бы правильно, только совсем правильно было бы это отличие на режим совместимости завязать.
Стояла 8.3.11.3... нашли баг с расширениями на 8.3.10 не было.
Решили поставить актуальный релиз 1С:Предприятие 8.3 (8.3.13.1513).
Посмотрим будет ли баг, а по описанию кучу ошибок исправлено, хотя у нас и не замечено было.
Оттестировал 64 битную версию конфигуратора скушал 10 гигов при формировании отчета по сравнению изменений. 32 битный падал уже на 2.3. В целом доволен!
Сегодня обновил платформу у клиента до 8.3.12.1685 х64. После попробовали обновить бухгалтерию до последнего релиза. Обновление из клиента "откатилось" назад из-за ошибки "backbas". Бухгалтерия базовая, вести надо 2 организации. Стоит 3 базы (одна для тестов). Открываться стала только одна база из 3. После удаления релиза и установки 8.3.12.1616 стало по-старому. Но обновление из клиента все равно не работает.
Версия 8.3.12.1616 и 8.3.12.1685. После использования команды "Печать на принтере" в печатной форме документа, перестает работать ПКМ и клавиши ESC, F1-12, пока не откроется какое-нибудь окно в 1С (например, Показать информацию о программе), или свернуть и развернуть программу, или ПКМ по панели задач. Проявляется везде - RDP, RemoteApp, тонкий клиент на рабочей станции, как на файловой, так и на серверной.
Если печатать через предварительный просмотр, то все ок.
При наличии РИБ, не советую ставить платформу выше 8.3.12, в которой добавили возможность работы с расширениями в РИБ.
1С:Предприятие 8.3 (8.3.13.1513). Одна из используемых конфигураций УТ 10.3. Распределенная база на 15 филиалов по двойной звезде. Win+SQL центральные базы и CentOs+Postgres филиалы.
После первого же динамического обновления (ДО) база перестала запускаться с ошибкой "Вызов обновления менеджера конфигурации не из конфигуратора". Обмены встали. Решили, что в новой платформе криворукие разработчики сломали ДО. Сделали изменения с реструктуризицией, отказались от режима совместимости и выгрузили на филиалы. Поскольку присутствует разница во времени, то рабочая половина филиалов, загрузив обновления, полностью проигнорировала присутствие конфигурации в сообщении обмена. Т.е. можно сказать, что обмен РИБ утратил заявленный функционал..
Далее нужно было как-то актуализировать конфигурацию на распределенных "нодах".
Попытались отключить базы филиала от главного узла через метод "ПланыОбмена.УстановитьГлавныйУзел(Неопределенно)" - не помогло. После повторного запуска предприятия либо конфигуратора, главный узел сам восстанавливался.
Вначале откатили на одном из филиалов платформу на 8.3.10, отключили от главного узла и загрузили cf основной базы.
Потом на остальных "поломанных" филиалах помог батник вида: "C:\Program Files (x86)\1cv8\8.3.13.1513\bin\1cv8.exe" DESIGNER /S"СЕРВЕР1С:ПОРТ\БАЗА" /N"ЛогинАдмина" /P"Пароль" /ResetMasterNode
Интересное замечание:
На нескольких филиалах мы вручную сделали обмен, переключив его с FTP на Локальный ресурс (через файл) и конфигурация на этих филиалах загрузилась. Т.е. обмен прошел штатно. Звучит бредово, но это факт. Сейчас нет возможности проверить, присутствует ли в файле сообщения на FTP изменения конфигурации. Соответственно не можем утверждать, что ошибка при обмене зависит от типа обмена (FTP/Файловый ресурс). Как выясним точно - отпишусь.
Так же после снятия совместимости перестали работать некоторые динамические списки основанные на запросах. В причинах ещё не разбирались.
В данный момент обмен между филиалами и центральными базами восстановлен. Думаем как жить дальше и куда писать, что бы сломали руки разработчикам фирмы 1С, которые пилят функционал расширений РИБ, с широко закрытыми глазами.
Провел опыт.
Сделали изменения в конфигурации. Выгрузил через FTP файл обмена - конфигурации в нем уже не было.
Последующие выгрузки через "файловый ресурс" так же не выгружали конфигурацию.
Все остальные обмены переключил на "файловый ресурс". Конфигурация выгружается и филиалы её принимают.
На основании этого можно сделать вывод, что при выгрузке сообщения обмена с изменениями конфигурации через FTP, программа эти изменения не выгружает.
8.3.13.1513. Три недели полёта.
- Баг с отвалом отладки на сервере локализован - проблема возникает при вызовах внешних обработок. Когда исполнение проходит через модуль объекта внешней обработки, то последующие точки останова могут не срабатывать.
- Проявилась давнишняя плавающая ошибка в веб-клиенте - не активируются элементы без обновления формы. Например, видимость и доступность одного элемента зависит от состояния другого - видимость включается, а доступность только после записи объекта (ака полного обновления формы).
- Отладка веб клиента тормозит так, что делается практически невозможной.
- В СКД появились новые "особенности". Например компоновка в привилегированном режиме не получает доступа к объекту если нет ни одной роли, по которой он просмотр, те отключается только РЛС.
Планируем 8.3.10 последнюю... Тестил на более новых 8.3.13 и 8.3.12 - глюки в обычных формах. 8.3.11 - вроде все нормально, но при выполнении большого количества однотипных операций с файлами словил ошибку "Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:", причем непонятны причины ее возникновения. На 8.3.10 пока полет нормально (на тестовом серваке), все работает как и подразумевалось.
(1939) Пользую 8.3.12.1595 уже пол года полет нормальный причем на клиентах х86 и х64 одновременно +100 пользователей. Проскакивают иногда глюки с двойной полосой прокрутки и свернутыми окнами.
(1944) да есть такое дело
Интересно, что вообще с 8.3.13 происходит, что на ней ERP 2.4.6 не рекомендуется запускать(((
Уже от 8.3.12.1469 пригорать начинает, глюкодром, да и плюшки расширений 8.3.13 нужны крайне, 8.3.14 пока не мечтаем.
Насильно ERP 2.4.5 перевели в режим совместимости 8.3.12, так же легко бы и в 8.3.13 перевели, но сама 1С говорит 8.3.13 под запретом... мрак
Через неделю нужно обновлять платформу, что делаем раз в полгода, а тут и выбрать не знаешь из чего...
Уже от 8.3.12.1469 пригорать начинает, глюкодром, да и плюшки расширений 8.3.13 нужны крайне, 8.3.14 пока не мечтаем.
Поставил на тестовый, но с ним сейчас почти ни кто не работает, так-что в работе ошибок ещё не всплыло.
А вот конфигуратор регулярно падает, причём как от самых простых действий, таких как ручное редактирование реквизита или связи в конструкторе запросов открытом в тонком клиенте, так и от совсем сложных - отмена захвата формы из хранилища с отменой всех изменений.
сегодня столкнулся с вот такой штукой, УТ11.3 платформа 1С:Предприятие 8.3 (8.3.13.1513), в обработке изменений никаких, все стандартно, значит это особенность платформы
починил, смешно, но блин если полезет еще что-то сменю платформу,
Использую 8.3.11.2899. Планирую всю самописную конфигурацию переводить на веб (поддержка совместимости стоит 8.3.9).
Стоит ли перед переходом обновлятся на более свежий релиз. И если да, то какой?
(1947) Да, стоит, как минимум на 8.3.13, а лучше сразу на 8.3.14. И "расширение для работы с файлами" больше будет не нужно.
У нас около 1к юзеров, проблем с этим расширением всегда было полно.
После перехода на 8.3.13.1513 столкнулись с очень необычной проблемой - в типовых отчетах (в т.ч. в Консоли отчетов) по оборотным регистрам перестали формироваться группировки по месяцам, дням и годам. Причем по остальным группировкам (секунды, минуты, кварталы, декады) все работает. Проблема проявляется во всех клиент-серверных базах. Кто-нибудь может сталкивался с таким?
1950.
user710223_sytdykovrr
04.01.19 12:18 Сейчас в теме
Работали на 1С:Предприятие 8.3 (8.3.8.1784) Клиент-сервер 4 года проблем небыло. сейчас заставляют хочешь не хочешь ставить 8.3.11.3133. Сегодня начнем процесс, потом отпишусь.
На платформе 8.3.12.1714 - в БП при расчете НДС уходил в бесконечный цикл и сервер рушился, когда занимал всю память.
Походу, это те самые "утечки памяти, которые мы устранили в 8.2... устранили в ... устранили в 8.3.. и окончательно устранили в ....)
Сейчас стоит 8.3.13.1690.
(1950)
8.3.13.1513 и 8.3.13.1644 ужасно глючная, постоянно отваливается отладка, динамические обновления проходят очень странно мягко говоря, начинаются странные баги по коду с получением параметров сеанса - помогает перезагрузка агента сервера 1с, группировки в динамических списках глючат (задвоение ссылок, хотя всегда было ок) Постоянная ошибка то не хватает памяти на сервере (хотя там ее полно), то нет доступа к каким то внутренним ресурсам 1с, то просто завершается сама собой. Откатились на 8.3.12. Лучше бы 1с не релизы платформ щелкала как орехи - а занималась тестированием, выпускала бы по 2-3 релиза платформы в год. но зато относительно протестированные., а тут у нас каждые 2 недели новая платформа и компании клиенты в место бета-тестеров
с ноября используем 8.3.12.1616 (до этого около года стояла 8.3.10.2772). базы КА 1.1, ЗУП 2.5, ЗУП 3.1, БП 3.0. клиент-сервер. пробовали работать как на отдельных серверах, так и объединять в кластер.
конфигурация кластера 2 центральных и 2 рабочих, отказоустойчивость 1.
проблемы с кластером:
1. задвоение сеансов из-за двух центральных серверов. требования назначения не помогли разрулить менеджеры по кластеру (может руки не туда прикладывал))).
2. глюки и зависания менеджера сеансов. пришлось включить режим отдельных процессов на каждый менеджер и убивать процессы вручную через диспетчер задач. для тонких клиентов норм, толстые почти всегда вылетают.
3. проблемы с распределением и миграцией сеансов по процессам и серверам.
4. проблемы с отладкой. мог не подключаться серверный сеанс при запуске отладки из конфига. практически невозможно отлаживать веб-сервисы - не подключает на лету.
в итоге пришлось от кластера отказаться. но и на отдельных серверах осталась часть ошибок, в основном с менеджерами сервера. периодически глючит менеджер сеансов и все сеансы просто завершаются с выкидыванием клиентов (толстых и тонких, без разницы).
также при сохранении конфигурации может выкинуть из конфига, при этом сама конфигурация к счастью успешно сохраняется без ошибок.
из плюсов заметил оптимизацию проверки вывода табличного документа (обычно используется при выводе строк в документ). оптимизация работает только если используется драйвер "живого" принтера, а не программный (например "Microsoft Print to PDF" или "Отправить в OneNote")
Стоит 8.3.14.1565.
Поставил из-за того, что повысили быстродействие на старом оборудовании, сервер 2003.
По нескольку раз падает в дамп, закономерность не выявлена. Всегда в разной ситуации и непредсказуемо.
Ужас..
До этого было 8.3.10 - без проблем, счастье! Как только поставили 8.3.12, и так далее 8.3.13 начались тормоза и никак не побороть их.
Оборудование никто обновлять не даёт.
8.3.14 при высоких нагрузках, начинают валиться rphost'ы, процесс циклический, тормозишь сервак, стартуешь, чистишь сеансы, и о счастье в ERP у всех кто был в базе слетает интерфейс пользователя, у кого что пропадет, у кого панель разделов, у кого в панели разделов часть кнопок типа кнопки открытия списка заказов в продажах....
Только после второго рестарта сервера 1С, помогает восстановить интерфейс юзерам, чистка локальных кэшей и настроек...
Ну справедливости ради нужно сказать это и на 8.3.13 наблюдалось несколько раз.
Потом, если в базе используются расширения, то ряд внешних обработок например поиск и замена значений перестают работать из-за того что при поиске объектов платформа рапортует, что в таком та документе такого-то расширения якобы не удалось инициализировать модуль менеджера из-за того что якобы в нем есть ссылки на методы общих типовых модулей ну типа управления печати и прочих, и тупо рестарт или завершить работу...
Однако все дописки в расширении прекрасно работают и не плачут, а катаклизмы неизвестно природы генерят...
УПП на 8.3.14, конфигуратор, список пользователей, пробуем открыть свойства любого юзера, вываливаемся с критической ошибкой "Структура данных не поддерживает хранение расширений. Необходимо отключить режим совместимости.".
К слову сказать расширения и не пытались на УПП юзать и режим совместимости стоит 8.2.13
На УПП обычные форму соответственно, юзеры отрубают случайно главное меню или иную панель инструментов (видимо в удачные дни при полной луне ночью) и потом назад она уже не включается.
Приходится сносить папки с настройками юзера...
Месяц как перевели КА 1.1 с 8.3.10.2753 на 8.3.12.1855 без режима совместимости, клиент-сервер MsSQL, ~70 пользователей, новых жалоб не обнаружено, окроме того что в обычном толстом клиенте формы можно перетянуть выше панели инструментов откуда их больше никак мышкой не вытащить, благо есть волшебная кнопка "восстановить положение окна"... пришлось всем объяснять как этим пользоваться. Из плюсов помимо новых фишек - конфигуратор пока не вылетал с ошибками, что было регулярным на 8.3.10. Конфа очень сильно переделанная, расширениями не пользуемся. Никаких падений кластеров, сервера и т.д. не было что раньше что сейчас. Где-то год назад сидели на 8.3.5.1625 - вообще монолит в плане стабильности.
Привет всем.
Есть у кого опыт внедрения / использования 1С:Предприятие 8.3 (8.3.15.1565) в высоконагруженных системах (от 100 до 600 пользователей)? На тестовых развернули вроде всё "ок", но разворачивать на продакшен пока боязно.
Мы однозначно не трогали планы видов расчета, доработки велись в не типовых документах в период с 26 по 27 число, в течении дня применяли динамически изменения, а ночью когда потребовалось монопольно провести обновление базы с реструктуризацией из-за того что размер одного текстового реквизита расширили, то вылезла ошибка. Потом даже без этого изменения и вторая база УПП, но уже тестовая с такой же ошибкой свалилась.
(1973) Мне не помогло. Делал ТиИ (было несколько попыток) - ошибка не ушла. Возникла после перехода на 8.3.16.1148. УПП 1.3.142.1. Помогло добавление кода к предопределенным элементам плана вида расчетов ДополнительныеНачисленияОрганизаций (у двух предопределенных элементов не было кода). После этого обновление прошло без ошибки. В других базах с аналогичной конфигурацией и также отсутствующим кодом предопределенных элементов, обновление могло проходить без возникновения данной ошибки (проблема обнаружена в 4х базах из 16). Полагаю, что при изменении предопределенных элементов механизм платформы перепрописывал номера таблиц и в этот раз не дублировал их.
(1974) Ну как бы у нас по совпадению база 402 гига, за 5+ часов все сделалось. Чисто реструктуризация отмеченная галкой в ТИИ, ничего другого не делали. Естественно такое только в ночь делать. База распухла до 820 гигов, потом сжатие не один час.
Сервер х 64, пользователей 70+, базы - 20 шт.
8.3.15.1534 - начали происходить одиночные "вылеты" пользователей. Так же появился эффект сворачивания программы, разворачивалась обратно только через Диспетчер задач.
Обновились на 8.3.15.1565. Сегодня с утра наблюдается ошибка "Не найден файл внешней компоненты" при создании нового сотрудника или открытия выписки зарплатной платежки, контрагентом в которой стоит группа сотрудников. Привлекаю программера 1С, после обеда должны быть результаты. Может и не платформа, но уж больно похоже, т.к. обновились в пятницу.
(1976) По ошибке "Не найден файл внешней компоненты" решением стал простой перезапуск службы сервера 1С. Пока не ясно, связано ли это с платформой, но все остальное работает стабильно.
в 1С:Предприятие 8.3 (8.3.15.1565) при режиме совместимости 8.3.5 "слетает"/разъезжается форма консоли запроса. Можно проверить в стандартной УТ 11.1.
Ни кто не в курсе исправили сей баг в других версиях платформы?
Отчет "Расчетные ведомости организаций"
1. В режиме без совместимости: выдаёт ошибку в запросе (в параметрах регистра среза остатков указано измерение с таким же именем, как и в другой части запроса, почему-то платформа считает это поле "неоднозначным", хотя какая может быть неоднозначность в параметрах, не понятно... самое интересное, что конструктор ошибки не видит, а при выполнении - вылет с ошибкой"
2. Если указать совместимость 8.3.14, то отчет ругается на сложение в запросе строк неограниченной длины. Если длину исправить, указав = 255, выводятся все поля, кроме Начального и Конечного сальдо...
3. Если указать совместимость 8.3.13, то отчет выводится верно. Без комментариев.
Вот и верь после этого в чудо производительность и прочее "новых" платформ...
П.С. 1С:Предприятие 8.3 (8.3.15.1700) - всё то же самое...
(1988) оно та может и не сложно, но:
1. кадров мало кто-бы потом понимал что там понастраивали
2. в базах по тонкому клиенту работают люди удаленно => еще и танцы с бубном вокруг Апача нужно проводить, а тут снова см. п.1
Порой делать лучше все проще, легче для понимания, легче потом переставлять платформы на новые версии (а раз в пол года делая, много чего из нюансов можно и позабыть при динамично выносящей мозг работе)
После обновления до 8.3.16 1030:
Возникла проблема с принтерами. Xerox и Canon работают, все HP выдают ошибку «Ошибка при получении характеристик принтера»
Так реагируют как сетевые, так и локальные принтеры.
Пока откатились на 8.3.15.1700.
(1990)
Планируем перейти на 8.3.15.1830 - стабильная или нет?
У нас сейчас 8.3.12.1595, но новые релизы конфигураций требуют платформу не ниже: 8.3.14.1976. Выбор падает на 8.3.15.1830.
Или посоветуйте, люди добрые, платформу не ниже 8.3.14.1976! )
Стоит неделю 8.3.15.1830, БП ЗУП последние, проблем нет
Самое неудобное в новом интерфейсе это "Все функции " теперь справо, постоянно лезу их слево ищу, или файл сохранить...
(1995) Как минимум в файловом режиме при загрузке конфигурации (типовых) не дает сразу обновить информационную базу, отваливается с критической ошибкой, повторный вход в конфигуратор решает проблему