Отказ от расширения конфигурации. Как перенести все изменения из расширения в основную конфигурацию
По теме из базы знаний
Найденные решения
(12) Обновил платформу до 8.3.12.1595. После удаления реквизитов система споткнулась в двух местах, до обновления - в пяти. По-удалял индексы у проблемных таблиц - сейчас уже не надо вспоминать про INSERT, DELETE и другие команды SQL (раньше вылезали дублирующие строки, сейчас - не заметил). Больше система не ругалась и "Некорректное использование LOCAL/GLOBAL в SET GENERATION" перестало вылазить. Для восстановления индексов пришлось запустить реструктуризацию и реиндексацию.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) ставить в конфигураторе для расширения отбор по измененным объектам и переносить их в основную конфигурацию ручками. Вот только уверены, что после этого все взлетит? Если логика не работала в расширении, то в основной у вас также не заработает: от перестановки мест в этом случае результат не поменяется) Начинайте с того, чтобы определите, действительно ли косячит механизм расширений, а не сами "дописки")
(4)Так и делаю, все ручками переношу.
"...Если логика не работала в расширении..." - откуда Вы это взяли? Все работало! Но по мере роста и работе с расширением кучей программистов все упало. Сейчас все это надо перенести.
"...Начинайте с того, чтобы определите, действительно ли косячит механизм расширений, а не сами "дописки") ..." - "дописки" не косячат ЖЕЛЕЗНО! Есть такое слово - архивирование. Так вот, архив такого расширения работает до сих пор и никто на эти "дописки" не жалуется. Только надо двигаться дальше, но что-то с расширением стало.
"...Если логика не работала в расширении..." - откуда Вы это взяли? Все работало! Но по мере роста и работе с расширением кучей программистов все упало. Сейчас все это надо перенести.
"...Начинайте с того, чтобы определите, действительно ли косячит механизм расширений, а не сами "дописки") ..." - "дописки" не косячат ЖЕЛЕЗНО! Есть такое слово - архивирование. Так вот, архив такого расширения работает до сих пор и никто на эти "дописки" не жалуется. Только надо двигаться дальше, но что-то с расширением стало.
(1) Не вижу смысла идти на попятную при первой проблеме.
Вы вообще как понимаю кроме аля отчетиков ничего не делали.
А попробуйте ERP перевести в 8.3.12 или даже в 8.3.13 и вкусить все возможности расширений.
Однако сначала придется по-воевать с типовой, так как она не заточена под такое, чтобы ее переводили в режим совместимости выше 8.3.10
Вы вообще как понимаю кроме аля отчетиков ничего не делали.
А попробуйте ERP перевести в 8.3.12 или даже в 8.3.13 и вкусить все возможности расширений.
Однако сначала придется по-воевать с типовой, так как она не заточена под такое, чтобы ее переводили в режим совместимости выше 8.3.10
(8)
Вы вообще как понимаю кроме аля отчетиков ничего не делали.
Данное утверждение не есть верное. Отчеты - это так, для развлечения. Там кое-где и кое-что свое имеется.
А попробуйте ERP перевести в 8.3.12 или даже в 8.3.13 и вкусить все возможности расширений.
Не я принимаю решения по этому вопросу.
(10) ERP 2.4.6 сейчас адаптируется 1С под 8.3.12, скорее всего сразу учтут возможности расширений 8.3.13.
Нет никакого смысла вам переносить наработки из расширения в типовую.
По опыту скажу, у нас ERP 2.4.5.86 переведена в режим совместимости 8.3.12, в одном месте вроде в типовой сделана поправка чтобы она могла вообще запуститься на 8.3.12 (заблочили проверку написанную 1С), потом в самом же расширении сделаны допилы чтобы типовая воспринимала документы/справочники/регистры сведений... из расширений и не валилась в ошибки. Это все есть уже в БСП 3.0.
На 8.3.13 пока не переходили, но уже сейчас понятно, что риск был оправдан, типовую вообще не трогаем, но так как возникает потребность в не типовых регистрах накопления, то скоро и на 8.3.13 перейдем.
Нет никакого смысла вам переносить наработки из расширения в типовую.
По опыту скажу, у нас ERP 2.4.5.86 переведена в режим совместимости 8.3.12, в одном месте вроде в типовой сделана поправка чтобы она могла вообще запуститься на 8.3.12 (заблочили проверку написанную 1С), потом в самом же расширении сделаны допилы чтобы типовая воспринимала документы/справочники/регистры сведений... из расширений и не валилась в ошибки. Это все есть уже в БСП 3.0.
На 8.3.13 пока не переходили, но уже сейчас понятно, что риск был оправдан, типовую вообще не трогаем, но так как возникает потребность в не типовых регистрах накопления, то скоро и на 8.3.13 перейдем.
А что расширение делает?
Если это отчеты, обработки - нужно писать внешние отчеты и обработки.
Если это изменение модулей основной конфигурации - нужно снимать с поддержки конфигурацию и вносить изменения в неё.
Можно разобраться почему расширение работает некорректно и его отладить.
Если это отчеты, обработки - нужно писать внешние отчеты и обработки.
Если это изменение модулей основной конфигурации - нужно снимать с поддержки конфигурацию и вносить изменения в неё.
Можно разобраться почему расширение работает некорректно и его отладить.
Как перенести: оставить на поддержке и включить возможность изменения.
В конфигурации есть общий модуль (модули) "модификация конфигурации" куда ведут многие события форм, там можно программно модифицировать формы. Использовать подписки на события, где возможно и т.п.
Где -то на инфостарте была статья как правильно это делать.
Сам так с ERP работаю, проблем с обновлениями не знаю.
В конфигурации есть общий модуль (модули) "модификация конфигурации" куда ведут многие события форм, там можно программно модифицировать формы. Использовать подписки на события, где возможно и т.п.
Где -то на инфостарте была статья как правильно это делать.
Сам так с ERP работаю, проблем с обновлениями не знаю.
(3) "В конфигурации есть общий модуль (модули) "модификация конфигурации" куда ведут многие события форм, там можно программно модифицировать формы. Использовать подписки на события, где возможно и т.п." - у меня есть свое руководство и оно, почему-то, думает что оно и есть истина! Да и вопрос стоит не "Как быть?", а "Что делать?" (с тем что есть).
"Сам так с ERP работаю, проблем с обновлениями не знаю." - Счастливчик.
"Сам так с ERP работаю, проблем с обновлениями не знаю." - Счастливчик.
Для конкретики:
Удаляю из расширения у объектов, перенесенных туда, все созданные реквизиты (при таком подходе при отключенном расширении не выходят ошибки в конфигурации при работе с объектами). У справочника Расчетные счета удалил реквизиты и пытаюсь сохранить эти изменения. Конфигурация не дает - выходит ошибка про нарушение уникальности индекса. Ради эксперимента решил устранить указанную конфигурацией причину - убираю все индексы в скуле у указанной таблицы. И, о чудо, все сохранилось, НО проблема с ТИИ! Не хочет теперь она индексацию делать. Неуникально получается, говорит. Лезу в эту таблицу и вижу по ключу две одинаковых записи. Хотя для ключа они одинаковые, а в целом - разные. Различаются только одним полем - версией, а в остальном, как две капли воды.
Удаляю из расширения у объектов, перенесенных туда, все созданные реквизиты (при таком подходе при отключенном расширении не выходят ошибки в конфигурации при работе с объектами). У справочника Расчетные счета удалил реквизиты и пытаюсь сохранить эти изменения. Конфигурация не дает - выходит ошибка про нарушение уникальности индекса. Ради эксперимента решил устранить указанную конфигурацией причину - убираю все индексы в скуле у указанной таблицы. И, о чудо, все сохранилось, НО проблема с ТИИ! Не хочет теперь она индексацию делать. Неуникально получается, говорит. Лезу в эту таблицу и вижу по ключу две одинаковых записи. Хотя для ключа они одинаковые, а в целом - разные. Различаются только одним полем - версией, а в остальном, как две капли воды.
(9)Имеется следующее на сайте
Код ошибки: 10197605
Код(ы) обращения: SW1298179
Описание:
При удалении расширения конфигурации, которое добавляет данные, происходит ошибка
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Некорректное использование LOCAL/GLOBAL в SET GENERATION
если расширяемая конфигурация имеет план видов характеристик с реквизитом обобщённого типа. Показать
Тоже такое наблюдалось.
Код ошибки: 10197605
Код(ы) обращения: SW1298179
Описание:
При удалении расширения конфигурации, которое добавляет данные, происходит ошибка
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Некорректное использование LOCAL/GLOBAL в SET GENERATION
если расширяемая конфигурация имеет план видов характеристик с реквизитом обобщённого типа.
Тоже такое наблюдалось.
(12) Обновил платформу до 8.3.12.1595. После удаления реквизитов система споткнулась в двух местах, до обновления - в пяти. По-удалял индексы у проблемных таблиц - сейчас уже не надо вспоминать про INSERT, DELETE и другие команды SQL (раньше вылезали дублирующие строки, сейчас - не заметил). Больше система не ругалась и "Некорректное использование LOCAL/GLOBAL в SET GENERATION" перестало вылазить. Для восстановления индексов пришлось запустить реструктуризацию и реиндексацию.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот