Ошибка динамического обновления 1с
Такие ошибки возникают обычно на старых версиях платформы. В настоящее они время проявляются очень редко (на 8.3 не встречалось ни разу).
Также замечу: в последней платформе 8.3.8 появилось долгожданное динамическое обновление в клиент-серверном режиме без перезапуска конфигуратора (ранее такое было только на файловых базах).
Можно долго говорить о том, что не надо пользоваться динамическим обновление, необходимо организовывать работу так, чтобы это происходило реже, но это документированный функционал платформы, соответственно он должен работать корректно.
Что же делать при такой ошибке?
- запомнить/записать точное время возникновения ошибки.
- сообщить всем о том, что ошибка известна, вы работаете над ее решением и база некоторое время работать не будет (далее игнорируете всех, кто не может вам помочь иначе вас затерроризируют вопросами)
- сделать полную копию базы данных
- развернуть(открыть) копию базы, где конфигурация соответствует составу реквизитов (они должны совпадать), код модулей и форм может отличаться (быть не актуальным)
- если есть отличия в реквизитах постараться «свести» конфигурации
Если копий нет, то в случае если конфигурация типовая и правки не затрагивают структуру данных, то разворачивайте типовую конфигурацию.
Далее, производите замещение конфигурации из «копии» в «исправляемую» базу
Для этого Запускаете SQL Management Studio и выполняете такой запрос:
В 99% случаев он вам поможет (мне помогало 3 раза). Исправление занимало от 5 до 20 минут.
Далее восполняете пробелы в коде. Если конфигурация подключена к хранилищу, необходимо синхронизировать захваченные объекты (отпустить и захватить заново), внести правки.
Если версия файловая произведите тестирование утилитой «C:\Program Files (x86)\1cv8\8.*.*.*\bin\chdbfl.exe».
При отсутствии конфигурации/копии:
- смотрите записи таблицы dbo.ConfigSave, при наличии — очищайте (пробуйте запустится)
- смотрите записи таблицы Config, на поле «FileName», если есть со значением «commit»,»dbStruFinal» или «dynamicCommit» — удаляйте
- либо в этой же таблице смотрите записи с именами подобными %_dynupdate_ % (здесь потребуется «по манипулировать» с датами и именами, но у меня не получалось)
Не помогло?
В остальных случаях придется поднимать и откатывать копии базы данных или транзакции (при полной модели восстановлении).
При небольшом документообороте может оказаться проще откатить базу на несколько минут назад — быстрее восстановить работоспособность (внести данные заново), чем поднимать другие копии.
Рекомендации
- Используйте полную модель восстановления
- Чаще делайте копии и базы, и конфигурации (в идеале: перед каждым обновлением)
- Используйте хранилище для разработки
- Держите рядом копию базы (это сэкономит время для восстановления)
- При подозрительных ошибках в момент обмена с хранилищем не обновляйте базу при работающих пользователях
В моем случае возникла ошибка snegopat-а при обмене с хранилищем, а затем такая же в момент обновления — с вытекающими проблемами.
Хороший дизайнер строит ясную структуру. А плохой напихивает все, что знает, и не может привести к своей мысли зрителя.
— А. Логвин
- «Сравнить, объединить с конфигурацией из файла», «Сравнить конфигурации» платформа не видит отличий, либо видит, но не все.
- При объединении конфигураций объекты метаданных откатывались до версий, которые были несколько обновлений назад.
Поиск готовых решений проблемы:
Поиск источника проблемы:
После тестовых динамических обновлений и просмотра технологического журнала нашел таблицы в которые система делает записи с признаком динамического обновления.
Система оставила старую версию обновляемого модуля и добавила новую версию с признаком динамического обновления (dynupdate в наименовании).
Каждая запись таблицы продублировалась с признаком динамического обновления.
После удаления записей из таблиц Config и Params, которые система сделала при динамическом обновлении, произошел откат сделанных обновлений.
Сделал копию проблемной рабочей базы и почистил таблицы Config и Params от лишних записей.
После чистки таблиц механизмы сравнения/объединения/загрузки конфигурации стали работать корректно и указанных проблем больше не возникало.
Данную процедуру провел на 22 базах.
1. Создать копии таблиц Config, Params для случая если что-то пойдет не так.
SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER ON
CREATE TABLE [dbo] . [< Имя _ таблицы >Copy]
[FileName] [nvarchar] ( 128 ) NOT NULL,
[Creation] [datetime] NOT NULL,
[Modified] [datetime] NOT NULL,
[Attributes] [smallint] NOT NULL,
[DataSize] [int] NOT NULL,
[BinaryData] [image] NOT NULL,
PRIMARY KEY CLUSTERED
) WITH ( PAD_INDEX = OFF , STATISTICS_NORECOMPUTE = OFF , IGNORE_DUP_KEY = OFF , ALLOW_ROW_LOCKS = ON , ALLOW_PAGE_LOCKS = ON ) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
2. Удалить записи, которые система создает при динамическом обновлении.
FileName like '%dynupdate%'
FileName like 'DynamicallyUpdated'
FileName like '%dynupdate%'
FileName like 'DynamicallyUpdated'
3. Обновить конфигурацию файлом с последними изменениями т.к. после чистки произойдет откат модулей, которые обновлялись динамически.
Специальные предложения
Мы просто отказались от динамического обновления. Этот механизм как не работал так и не работает у 1с.
maklyak; andry888; sashapere; SuhoffGV; omut; artbear; vladir; webester; cool.vlad4; tormozit; theshadowco; Stim213; Yashazz; Йожкин Кот; + 14 – Ответить
Динамическое обновление это верный способ нажить себе проблем. А потом с ними героически сражаться.
За решение спасибо! Может пригодиться. А то пару раз встречал базы кем то динамически обновленные.
все ж таки один проход лучше, чем два =) тем паче что оба не оптимизируемы
крута было б ежели все это дело обернуть в ADO и сделать в виде родной обработки 1С с одной лишь кнопкой "Сделать все хорошо" =)
Спасибо, за решение. Динамикой увы приходится пользоваться. но вот таблиц таких слава богу оказалось не так много.
(6) DAnry, например? мое мнение, если без динамич. обновления никак, то что-то явно делается не так.
Для файловых баз, расшаренных по сети, это однозначно геморрой и проблемы.
При динамическом обновлении основная проблема возникает не на сервере SQL, а на клиенте, у которого не обновляется кэш или кэш разрушается. В результате при следующем входе в систему пользователь получает не ту версию конфигурации, которая ожидается, или получает ее не полностью.
(7) recon, проблема была в том, что при монопольном обновлении платформа с какого-то момента перестала удалять записи сделанные динамическим обновлением. В некоторых базах таблица Config хранила десятки версий одних и тех же объектов. Для таких баз при выполнении сравнения/объединения конфигураций платформа не видела различий в файлах, а при выполнении команды объединения/загрузки конфигурации из файла, считала последней версией объекта одну из старых неудаленных.
(9) Valp,
Я у десятка клиентов пользуюсь динамическим обновлением. Проблем не возникает.
Точнее. один раз возникла у клиента, у которого мы просто переставили 1С сервер с 8.2.16 на 8.3.4 без выгрузки/загрузки через DT. И то, проблема возникла у всех, у кого когда либо открывали конфигуратор и открывали в нём конфигурацию.
А так, как я сказал, проблем ни каких. Есть даже один клиент у которого я по 30 раз за день делаю динамическое обновление (клиент-сервер 8.2.19.106, MS SQL 2012).
Может Вы не умеете "готовить 1С"? :-)
(10) EmpireSer,
Видимо ты знаешь что-то чего не знают другие, может тебе Борис какой-то секрет рассказал?
Сколько активных юзеров в базе, которую ты в день по 30 раз обновляешь? После таких изменений обычно база долго не живет. По теме, если выгонять всех юзеров после каждого динамического обновления (грубо говоря одно обновление в день), то скорее всего "пронесет", но с 30-кой в день, это не реально.
Ну отказываться от динамического обновления не вижу смысла. А вот использовать хранилище конфигурации всецело устранит эти проблемы. Зачем разрабатывать какой-то кф-ник потом мучаться со сравнениями?
(11) logarifm,
Для разработки используем хранилище, файл с нужными изменениями выгружаем и отправляем в живые базы,
они обновляются монопольно в пакетном режиме. Проблему получили при очередном таком обновлении, сразу после перехода на новую платформу. Отправили файл с изменениями, по логам все прошло успешно, но по факту в конфигурации БД получили откат некоторых объектов к версиям, которых не было ни в конфигурации которую обновляли, ни в конфигурации которой обновляли. При попытке ручной загрузки, получили то же результат. При сравнении конфигураций оказалось, что платформа не видит изменений. Проблема возникла почти на всех базах, для которых перешли на новую платформу.
(12) Valp, все эти пляски с бубном от того, что 1с вряд ли опубликует алгоритмы процесса обновления
такие дела
(13) Fox-trot,
Вообще-то он довольно понятный. Даже можно сделать сравнение до и после изменений распаковывая данные в "BinaryData".
(0),
Всё таки "костыль" исправления уже сделанного не правильного перехода описан хорошо.
Но в статье не хватает описания правильного перехода, где не возникнет таких проблем.
Так же Вы не описали как осуществлялся переход с 8.2.17 на 8.3.5, т.е. сами этапы.
(14) EmpireSer, то есть тебе еще не попадалиь случаи когда сравнение не показывало различие всего одного свойства, к примеру в макете, хотя ты точно его изменял
раз уж тебе известно больше чем окружающим, может поделишься кодом 1с сравнения конфигураций. для серверного варианта есесьно
Один раз произошло так, что факт того, что изменения откатились всплыл где то через пару месяцев. После этого стараюсь не трогать динамическое обновление, можно очень сильно потом об этом пожалеть.
Просмотры 26447
Загрузки 0
Рейтинг 69
Создание 11.11.14 19:14
Обновление 11.11.14 19:14
№ Публикации 312157
Тип файла Нет файла
Конфигурация Конфигурации 1cv8
Операционная система Windows
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
Код открыт Не указано
См. также
Как я начал администрировать сервер 1С: Предприятие 8.3 с телефона Промо
Развитие инструментов управления кластером серверов 1С:Предприятие 8.3.
14.04.2017 68974 user700211_a.straltsou 30
Динамическое обновление - это зло?
Копнем глубже в тему "Что же такое динамическое обновление" и почему оно может привести к проблемам. И может ли?
09.05.2022 3803 YPermitin 53
Ферма ОДИНа или как управлять множеством Серверов 1С: Предприятие из одной точки
У Вас много серверов приложений 1С Предприятие разных версий и их надо мониторить и администрировать. Новое приложение для управления фермой ОДИНа как раз для тебя.
26.08.2021 1432 khorevaa 8
Легкий способ регистрации библиотеки COMCNTR.DLL (для COM-соединения)
Устали от командных строк, нюансов с разрядностью 32х/64х или ручного создания V83COMConnector в службе компонентов? Предлагаю простой способ регистрации библиотеки COMCNTR.DLL.
22.12.2020 35622 vakrikun 32
Копирование числовых ячеек из 1С в Excel Промо
15.01.2019 38395 itriot11 27
Выгрузка в dt на сервере 1С по расписанию с завершением соединений и подключением к консоли сервера через com
Была задача настроить по расписанию выгрузку серверной базы в dt, готового решения не нашел, делюсь, может, кому пригодится.
Вдаваться в подробности, что такое динамическое обновления, как оно полезно и как оно вредно я не буду, так как статей на эту тему уже много, так же как и способов ее решения. Просто расскажу о своем опыте и о требовании для разработчиков 1С, которое было введено в компании на основе этого опыта.
Динамическое обновление - это, конечно, нехорошо, но порой других возможностей просто нет. К примеру, компания, работающая 24/7 с количеством людей, работающих в базе, от 100 человек. Когда всех выгнать из базы и провести обновление очень затратно и необходимо заранее это согласовывать, тогда приходится использовать динамическое обновление. Сама ошибка заключется в том, что в момент записи в таблицу «Config» что-то произошло, что помешало корректно закончить данную процедуру. И существует два основных способа лечения этой проблемы:
- Первый - это удалить записи о том, что конфигурация обновлялась (не рекомендую, так как у меня не всегда корректно работало).
- Второй способ - перезаписать все данные в таблицы «Config» из резервной копии вашей рабочей базы.
Второй способ более надежный, но была проблема в том, что необходимо было поднимать и разворачивать SQL-ный бэкап, что занимало много времени.
И поэтому придумали простой и надежный механизм. Перед каждым динамическим обновлением просто сохранять таблицы «Config» и «ConfigSave» (Сохранять ConfigSave» не обязательно, мы делали, чтобы сохранить сделанные наработки в конфигурации).
Создал внешнюю обработку с двумя кнопками «Сохраниться перед динамическим обновлением» и «Восстановить данные после ошибки динамического обновления».
Копка «Сохраниться перед динамическим обновлением» вызывает процедуру:
Копка «Восстановить данные после ошибки динамического обновления» вызывает процедуру:
[master].[dbo].[sp_backup_config_tables] и [master]. [dbo].[sp_restore_config_tables]
Это процедуры в SQl.
[master].[dbo].[sp_backup_config_tables]
[master]. [dbo].[sp_restore_config_tables]
При нажатии кнопки «Восстановить данные после ошибки динамического обновления» блокировать работу пользователей не надо. Те, которые уже работают, ничего не заметят, а новые зайти не смогут.
Если раньше такая ошибка считалась критичной и время восстановления занимало до 1 часа, то теперь оно сократилось до 5 минут.
Специальные предложения
Ну действительно, извечная проблема. Решение только такое - постараться не обновлять динамически, или если уж произошла проблема, то почистить кеш у пользователя, где проблема возникла.
(1) patimka, кэш чистить далеко не всегда помогает в силу того, что изменения в базу зачастую уже записаны и записаны как раз с ошибкой. кэш поможет, только если все сохранилось, а у пользователя нет изменений.
для скульных баз действительной хороший способ описан.
вопрос автору: обязательно в master процедуры добавлять или можно в любую другую базу? я не силен в языке запросов, так что можно пояснения по поводу имен объектов и что где храниться в итоге?
(2) Lord_Michael, Поместить процедуры можно куда угодно,важно чтобы к ним был доступ. Помещать их в рабочую базы не рекомендую , так как к примеру при загрузки данных средствами 1С (dtшник) ваша процедура затрется. А в мастере она будет в надежной сохранности. В итоги при сохранение, данные хранятся в Databases\System Databases\master\Tables\dbo.Config_Backup
где dbo.Config_Backup - это таблица , полностью скопированная с таблицы dbo.Config вашей рабочей базы
(3) ChiginAV, По началу так и хотели сделать,но в действительности реализовать не получилось. Дело в том что 1С использует SQL как хранилище данных , а сам процесс динамического обновления производит платформа и в SQL пишутся данные уже по факту. Отловить триггером этот механизм в платформе не получится, единственное что вы можете это получить момент когда таблица начнет меняться. Но для восстановления нужна таблица до изменения , поскольку остановить процесс записи в нее нельзя, а попытка замедлить этот процесс приводила к ошибкам в платформе. Да и сам процесс копирование записей занимает время, у меня это от 3 до 8 секунд ( Комплексная Автоматизация - 25847 строк в таблице Config и необходимо помнить,что каждая запись не просто текстовые данные, к примеру ячейка [BinaryData] - по сути архивированный файл с описанием метаданного ,а они бывают относительно тяжелыми, к примеру: запись содержащая файл с конфигурацией поставщика от Комплексной Автоматизации весит 261 МБ ).
почти 10 лет на промышеннЫХ базах используется
(7) German, Ну по презентации не понятно как именно она работает. А ссылка интересная,на досуги по изучаю. Но по мне ручной контроль этого менее трудозатратный. И скорее всего при разработке "Хранилища" были задействованы люди знающие как работает этот механизм в платформе 1С. В примере была предоставлена конфигурация ЗУП она довольно простая , разумней было бы показать примеры на УПП и уже на ней говорить о скорости работы. Я пробовал ставить триггер на изменение таблицы и копировал всю ее,а в "Хранилище" скорее всего сохраняется только измененные объекты. Распаковать и получить структуру конфигурации это не проблема V8Unpack20 в свободном доступе причем с его помощью можно не только распаковывать, но и обратно запаковать метаданное и поместить его в SQL , вопрос только в том на сколько это корректно и правильно. На мой взгляд о прямой записи в SQL стоит всерьез говорить только когда 1с выпустит API. 1С бывает сама внезапно перестает работать и сваливаться в дамп :-)
Неужели ж оно настолько часто происходит, что прям вот такая автоматизация нужна?
Просто восстановить конфиг из суточного бэкапа раз в год - не вариант?
(11) AlX0id, Происходит не так часто, но поскольку компания работает 24/7 то простой не кому не нужен, а если простой по вине программистов то время простоя вычитается из их жалования:-). Вся проблема во времени восстановления. А динамически обновляемся в день раз 4-5 точно.
(12) Kondratenko.as,
Ну мы тоже не редко обновляемся демонически. Необходимость пересадки конфы возникала лишь пару раз за последние пять лет (тьфу-тьфу-тьфу).
// ЗЫ. Вот прям сегодня вылезла "Нарушена целостность конфигурации" при старте конфигуратора у одного из клиентов. Сглазил чо ли.. Вроде обошлось отключением/подключением ИБ на сервере 1С..
(12) А можно поточнее раскрыть "не так часто" (ну, если не тайна)?
У нас система всего лишь 12/5, сотня пользователей, обновления раз 10 в неделю (по дням неравномерно), страшное случилось 1 раз за 5 лет.
судя по тексту храгимок есть вероятность восстановления конфига соседней базы. то есть если выполнить бекап одной базы, то с легкостью мона восстановить в другой
(15) Fox-trot, Данный пример был создан для одной рабочей базы,чтоб можно было сделать вызов из любой базы,а не только из рабочей.
На мой взгляд, это все костыли. Если база данных находится на MS SQL сервере выше или 2005 и база данных имеет Full логирование и бекапы трензакт лога то можно воспользоваться официальной инструкцией msdn.microsoft.com и восстановить базу до момента нажатия на кнопочку "обновить базу данных". Ну, а по поводу очистки таблицы конфигурации это не всегда спасает.
(20) narus1,
решение же как раз предлагается без потери данных, как в случае отката по всему логу транзакций - перетирается только таблица с конфигурацией
Согласен если это делает автомат. Но мне интересно посмотреть тому человеку в глаза который после динамического обновления не запускает предприятие, и к тому же 1с вылетает при самом обновлении. То есть если у тя при этом работают 100 клиентов в этом есть смысл. Как говориться вернуть в зад :-).
(23) Zhilyakovdr, Зачем дропать? Вам тогда придется и создавать ее заново всякий раз , лишнее время тратить на выполнение
(27) Kondratenko.as, можно и не дропать, но тогда предварительно, при первом запуске, необходимо убрать truncate иначе вылетит с ошибкой т.к. при первом запуске нет еще таблицы для очистки.
а у нас просто память течет на 1С Сервере после динамического обновления) потом юзеров выкидывает с ошибкой типа Недостаточно памяти на сервере) хотя там памяти этой еще завались
(24) AllexSoft, версия платформы не 8.3.5.1383 случайно? Там есть баг с утечкой памяти рабочего процесса, в одной из наших организаций наблюдался.
(28) Puk2, 8.2.19 ) ту же беду наблюдал на 8.3.4.*, на последних 8.3.4 вроде убрали (ну во всяком случае так дико течь перестала)
Мне помогло для Postgresql :
Первые 2 пункта позволяют войти в конфигуратор, 3й пункт позволяет сохранять конфигурацию.
1) delete fr om configsave where FileName = 'commit'
2) delete from configsave wh ere FileName = 'dbStruFinal'
3) C:\Users\kub\AppData\Local\1C\1cv8 удаление всех папок кроме logs
Хорошо. Однако если последствия ДО вылезли например через неделю. Как вариант у пользователя начала форма справочника номенклатура некорректно отображаться. Чистка кэша пользователя помогает но потом снова появляется, хотя ДО более не делалось
Заморочился переделом написанного функционала без открытия SQL вообще, по похоже, что в старших версиях это уже не работает. Пробовал на 8.3.16.
Процедура Сохраниться()
Connection=Новый COMОбъект("ADODB.Connection");
Connection.ConnectionTimeOut =6000;
Connection.Open("Provider=SQLOLEDB.1;Password="+ПарольSQL+";Persist Security Info=True;User ;Initial Catalog="+SQL_ИмяБазы+";Data Source ADODB.Command");
Command.ActiveConnection = Connection;
Command.CommandText +SQL_ИмяБазы + "].[dbo].[Config];
|
|
| IF OBJECT_ID( 'dbo.ConfigSave_Backup' ) IS NOT NULL
| truncate table [dbo].[Config_Backup];
| else
| CRE ATE TABLE [dbo].[ConfigSave_Backup](
| [FileName] [nvarchar](128) NOT NULL,
| [Creation] [datetime] NOT NULL,
| [Modified] [datetime] NOT NULL,
| [Attributes] [smallint] NOT NULL,
| [DataSize] [int] NOT NULL,
| [BinaryData] [image] NOT NULL,
| [PartNo] [bit]);
|
| ins ert into [dbo].[ConfigSave_Backup]
| sel ect * fr om ["+SQL_ИмяБазы + "].[dbo].[ConfigSave]";
RecordSe t = Command.Execute();
далее идет исходный код .
Процедура Восстановиться()
//Подключение к SQL
Connection=Новый COMОбъект("ADODB.Connection");
Connection.ConnectionTimeOut =6000;
Connection.Open("Provider=SQLOLEDB.1;Password="+ПарольSQL+";Persist Security Info=True;User ;Initial Catalog="+SQL_ИмяБазы+";Data Source ADODB.Command");
Command.ActiveConnection = Connection;
Command.CommandText + SQL_ИмяБазы +"].[dbo].[Config];
|
| truncate table [" + SQL_ИмяБазы +"].[dbo].[ConfigSave];
|
| ins ert in to [" + SQL_ИмяБазы + "].[dbo].[Config]
| sel ect * fr om [dbo].[Config_Backup];
|
| ins ert in to [" + SQL_ИмяБазы + "].[dbo].[ConfigSave]
| sele ct * fr om [dbo].[ConfigSave_Backup]";
В итоге после восстановления при входе в базу, вылетает с ошибкой в дамп. Конфигуратор открывается, но нет прав на открытие конфигурации. Что-то сделано не так или вообще сейчас не работает?
Работаю с обработкой или общей формой . Меняю значение реквизита / меняю код добавляю новые процедуры или функции.. Т.е. все как обычно. Делаю динамическое обновление программы. У всех пользователей которые зашли после обновления все изменения работают. Все как надо. Я не закрываю конфигуратор. 1 закрываю объект с которым работал . открываю его опять и там все как было до изменения. Конфикоратор говорит что база не изменялась, но если я запущусь в режиме отладки то все внесенные изменения ранее пропадают. . Если перезапустить конфигуратор - все становится на свои места. Изменения появляются. Но после любого изменения и динамического обновления опять откат. кто сталкивался? как лечится?
(0) 8.3.10.2466 - у меня пару раз было подобное безо всякого динамического обновления. Вылечил ребутом тестового сервера -
аптайм был где-то 3 недели, а авторебута не было.
Конфикоратор глюкнуло от демонического обновления.
остановить 1с(если клиент-сервер, то сервер тоже). дропнуть кэш(если клиент-сервер, то сервер тоже). запустить 1с(если клиент-сервер, то сервер тоже).
"Здравствуйте, меня зовут Алексей и я делаю динамическое обновление.
Раньше, я делал динамическое обновление по три или даже целых пять раз в день.
Я мог не спросить пользователей, не сделать бекап средствами СУБД и динамически обновить базу ради изменения макета печатной формы счета на оплату.
Но потом случилось горе и в одно прекрасное обновление база просто не запустилась.
Это был ч0рный день в моей жизни.
Я потерял друзей, коллеги отвернулись от меня.
Жена меня бросила и дети не хотят со мной разговаривать.
Попа болела после долгого и многозначительного разговора с начальством.
И я решил изменить свою жизнь.
Я теперь занимаюсь спортом
Стал посещать бассейн.
Питаюсь правильно и соблюдаю правила дорожного движения.
Сегодня у меня праздник.
Я уже 30 дней не делаю динамического обновления без ахивации базы данных средствами СУБД.
Я практически готов полностью отказаться от динамического обновления.
Вообще не обновлять динамически.
Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:
12 ШАГОВ , РАЗРАБОТАННЫЕ САМИМИ ДИНАМИЧЕСКИМИ ОБНОВЛЯЛЬЩИКАМИ
1. Признать свое бессилие перед поведением платформы 1с при динамическом обновлении.
2. Согласиться с утверждением, что без посторонней помощи не обойтись.
3. Мысленно перепоручить себя некой Высшей силе, которая поможет.
4. Проанализировать свои поступки.
5. Признать перед собой и кем-то еще свои ошибки.
6. Не сомневаться, что бекап перед динамическим обновлением сработает.
7. Просить высшие силы избавить от недостатков.
8. Составить список всех людей, кому причинили зло, и захотеть загладить свою вину перед ними.
9. Лично возместить этим людям ущерб, нанесенный вами и вашим динамическим обновлением.
10. Продолжать самоанализ и, при малейших ошибках, сразу признавать, что вы их таки совершили.
11. Не переставать размышлять и благодарить помощника из пункта 3.
12. Достигнув пробуждения, благодаря пунктам 1-11, помогать другим динамическообновлялщикам.
Так почему же иногда, после внесения очередных изменений в конфигурацию 1С платформа предлагает "Завершить сеансы и повторить", а иногда "Обновить динамически"? Ответы на эти и другие вопросы, вы узнаете далее!
Особенности динамического обновления
К сожалению, обновить получится далеко не все. Обновить можно только то, что не касается структуры данных, что не вызовет процедуру реструктуризации, следовательно добавить/удалить документ, справочник, регистр, константу, реквизит документ, справочника и т.д. не получится. А вот изменить модуль проведения, модуль формы, внешний вид формы, макет, роль, подписку на событие, интерфейс, добавить/удалить отчет, обработку как раз можно! Естественно, после внесения изменений, пользователю, который хочет использовать эти изменения, придётся выйти и зайти в программу заново, чтобы платформа 1С загрузила новые данные. К примеру: после внесения нового функционала, были выявлены ошибки проведения документа. Разработчик имеет возможность внести коррективы и попросить перезайти только тех, кто работает с этим документом. Остальные пользователи, которые не имеют необходимости в работе с этими данными, могут спокойно продолжать работу, ничего не подозревая о внесенных изменениях.
Объекты, доступные и не доступные для динамического обновления
Список объектов, доступных для динамического обновления:
Список объектов, НЕ доступных для динамического обновления
- Регламентные задания
- Общие реквизиты
- Планы обмена
- Реквизиты, предопределенные элементы, иерархия, владельцы, нумерация справочников
- Реквизиты, нумерация, движения, последовательности, ввод на основании документов
- Перечисления
- Тип значений характеристик, реквизиты, нумерация, предопределенные элементы планов видов характеристик
- Реквизиты, нумерация, субконто, предопределенные элементы планов счетов
- Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
- Реквизиты, регистраторы регистров сведений, накопления, бухгалтерии, расчета
- Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
- Реквизиты, адресация, нумерация задач
- Реквизиты, нумерация, ввод на основании бизнес-процессов
Плюсы и минусы динамического обновления
Несмотря на неоспоримые удобства, динамическое обновление имеет и ряд минусов, из-за которого в среде программистов 1С, его часто называют "демоническим".
- Основное преимущество - отсутствие необходимости завершать все сеансы соединения с информационной базой (выгонять всех пользователей). Следовательно, нет никакой необходимости останавливать работу всей организации из-за мелочей, а ведь это может быть и 1000 человек.
- Из первого пункта вытекает следующее преимущество: увеличивается скорость разработки, следовательно, и эффективность всего решения в целом. Цепочка внедрения нового функционала может быть сокращена до следующей: сбор данных-анализ-планирование-разработка-внедрение-динамическое обновление-результат
- Чтобы изменения применились у конкретного пользователя, ему необходимо перезапустить программу. Но даже если существует необходимость перезайти конкретному человеку, это удобнее, чем останавливать работу всех.
- Возможные ошибки после такого обновлении. Связано это с тем, что каждый пользователь работает со своей версией алгоритмов информационной базы. Поэтому, иногда возникают ситуации, когда изменений не видно, или видно их частично, что может крайне критично сказаться на работе системы. Это проблема решается чисткой кэша или обращением к специалистам 1С
- Были известны случаи, когда "демоническое обновление" останавливало работу всей системы, а исправление последствий отнимало уйму времени или базы восстанавливали из копии, потеряв часть данных. Для решения этой проблемы, нужно регулярно обновлять платформу 1С, так как в каждом последующем релизе, стабильность платформы улучшается. Для решения этой проблемы нужны опытные специалисты.
Так стоит ли использовать динамическое обновление?
Динамическое обновление - несомненно, удобный и полезный механизм. Но, к сожалению, имеющий свои серьёзные минусы, которые сильно отпугивают многих программистов 1С. К сожалению, 1С не позволяет вести полноценную разработку, при наличии сеансов пользователей в ней, но динамическое обновление может выручить в экстренных ситуациях. Поэтому, рекомендуем использовать такое обновление только в крайних случаях, когда необходимость срочных изменений неоспорима. Также, рекомендуется настроить автоматическое копирование баз 1С, или делать копии достаточно регулярно. В остальных случаях, рекомендуется вести разработку таким образом, чтобы не возникала необходимость во внесении изменений при наличии сеансов соединения с информационной базой, т.е. новые механизмы отлажены, оттестированы и выверены на столько, что все идеально работает и не требует вмешательств!
Читайте также: