Comments 12
Заикнулись про перезапуск, объясните, пожалуйста, что там не так, кто виноват и что делать. Я устал бороться с 1с.
У нас рабочая и тестовые базы находятся в одном хранилище конфигурации. Тестируем код в тестовой базе, потом через хранилище помещаем в рабочую. Очень часто 1С дает возможность обновить рабочую базу динамически. Но, не всегда это обновление проходит гладко. Иногда так происходит, что конфигуратор просто зависает на попытке обновить конфигурацию базы данных. Это происходит у меня на 1С 8.2.15.319. После снятия процесса конфигуратора и повторном открытии его, он ругается, что «прошлое обновление было завершено некорректно, хотите продолжить обновление?». Но продолжение обновления также подвешивает конфигуратор. Я выхожу из ситуации так. Останавливаю сервер 8.2.15, запускаю сервер 8.2.14, а на нем уже конфигуратор сам продолжает оборвавшееся обновление.
Я об этой проблеме отписался разработчикам, скинул им дампы процессов в момент зависания конфигуратора. Они сказали, что эту ошибку планируют исправить только в версии 8.3. Так что…
Не знаю, у всех ли так происходит, связано ли это с нашими настройками сервера, наличием IIS или еще с чем-нибудь, но до выхода 8.3 приходится бороться.
И да, разработчики также утверждают, что обновлять базу так, как это делаю я, неправильно, и может привести к полному разрушению базы данных. Аргументируют различной внутренней структурой баз данных для версии 8.2.14 и 8.2.15.
Я об этой проблеме отписался разработчикам, скинул им дампы процессов в момент зависания конфигуратора. Они сказали, что эту ошибку планируют исправить только в версии 8.3. Так что…
Не знаю, у всех ли так происходит, связано ли это с нашими настройками сервера, наличием IIS или еще с чем-нибудь, но до выхода 8.3 приходится бороться.
И да, разработчики также утверждают, что обновлять базу так, как это делаю я, неправильно, и может привести к полному разрушению базы данных. Аргументируют различной внутренней структурой баз данных для версии 8.2.14 и 8.2.15.
Достаточно:
1) периодически чистить локальный «кэш» 1С на компьютере где проводится обновление
2) при сбое динамического обновления очистить в базе SQL таблицу Config_save (новая-непримененная структура конфигурации)
3) если п.2 не помог, проверить наличие свежих записей в таблице Config содержащие в имени файла *Commit* и удалить эти строки.
4) если п.3 не помог, подменить Config на Config предыдущей структуры, взятый из бэкапа.
Итого если без «динамического обновления» жизнь скучна, всегда имейте предыдущую версию таблицы Config.
1) периодически чистить локальный «кэш» 1С на компьютере где проводится обновление
2) при сбое динамического обновления очистить в базе SQL таблицу Config_save (новая-непримененная структура конфигурации)
3) если п.2 не помог, проверить наличие свежих записей в таблице Config содержащие в имени файла *Commit* и удалить эти строки.
4) если п.3 не помог, подменить Config на Config предыдущей структуры, взятый из бэкапа.
Итого если без «динамического обновления» жизнь скучна, всегда имейте предыдущую версию таблицы Config.
Динамическое обновление, само по себе вещь в себе. Иногда его использование приводит к забавным последствиям, но чаще к печальным. Вы конечно молодцы, что придумываете, перезапуск сервера, могу предположить, что следующим вашим шагом будет автоматическая очитска кэша пользователя который подключился к базе после обновления, может еще какие то меры, но ответ лежит в другой плоскости: не используйте динамическое обновление, особенно если изменения чуть больше чем: «вот здесь цвет формочки надо поправить и вот тут опечатка в надписи». У вас есть возможность перезапускать сервер, но нет возможности поймать момент когда нет пользователей в базе Причем вместо перезапуска сервера можно же как раз накатывать изменения? А если изменения затрагивают структуру базы данных и динамическое обновление невозможно, вы находите же возможность обновить БД?
Как вам сказать?.. Я знаю, что динамическое обновление — полузло, ибо о надежности его можно только догадываться. Знаю, что при динамическом обновлении пользователи не всегда видят эти обновления даже после перезапуска клиента. Стараюсь не злоупотреблять этим делом, а обновлять рабочую базу в конце дня или в обед.
Этим скриптом я не стараюсь найти момент, когда пользователей нет в базе. У нас большая организация. Вернее, я — сотрудник оутсорсинговой фирмы. У нас есть база УПП (переписанная), в которую сливаются данные из 28 филиалов, а потом запускается закрытие месяца. Часто этот процесс оставляют на ночь. Я же хочу запускать планировщиком перезапуск сервера рано утром. Но надо проверять, нет ли кого в этой базе закрытия (не выполняется ли работа по закрытию). Вот для этого и написал сей скрипт.
Этим скриптом я не стараюсь найти момент, когда пользователей нет в базе. У нас большая организация. Вернее, я — сотрудник оутсорсинговой фирмы. У нас есть база УПП (переписанная), в которую сливаются данные из 28 филиалов, а потом запускается закрытие месяца. Часто этот процесс оставляют на ночь. Я же хочу запускать планировщиком перезапуск сервера рано утром. Но надо проверять, нет ли кого в этой базе закрытия (не выполняется ли работа по закрытию). Вот для этого и написал сей скрипт.
Имелось ввиду, что в динамическом обновлении нет смысла, если у вас есть возможность перезапускать сервер, накатывайте в этот момент обновления, тогда и исправлять будет нечего.
полузло, это вы мягко, вы наверняка бываете на тематических форумах и гугл там по слову динамическое или демоническое обновление, выдает много пикантных подробностей. У нас к примеру, был случай, что он взял и заменил половину доработок то ли старыми версиями, то ли чем то из кеша, я не знаю, но код в конфигурации оказался месячной давности. За это время сами понимаете было сделано очень много. Получилась сборная солянка из старых недописок и новых доработок. Так как все вместе это проходило синтаксический контроль, сказать в какой момент «слетели» изменения сказать невозможно. Такие вот последствия динамического обновления.
полузло, это вы мягко, вы наверняка бываете на тематических форумах и гугл там по слову динамическое или демоническое обновление, выдает много пикантных подробностей. У нас к примеру, был случай, что он взял и заменил половину доработок то ли старыми версиями, то ли чем то из кеша, я не знаю, но код в конфигурации оказался месячной давности. За это время сами понимаете было сделано очень много. Получилась сборная солянка из старых недописок и новых доработок. Так как все вместе это проходило синтаксический контроль, сказать в какой момент «слетели» изменения сказать невозможно. Такие вот последствия динамического обновления.
// черная рамка на книге смотрится как страшилки на сигаретах
Честно говоря, не понял, чем сей «True Linux way» отличается от использования любого другого языка. По сути всё что делается — создаётся COM-объект и используется в хвост и в гриву, а затем вызываются две shell-команды, то же самое будет выглядеть практически так же на любом другом языке. Логичней было бы написать то же самое на PowerShell, тогда и перл бы ставить не пришлось.
Думаю, значтельно интересней для многих был бы аналогичный скрипт для Линуксового сервера 1С.
Думаю, значтельно интересней для многих был бы аналогичный скрипт для Линуксового сервера 1С.
Sign up to leave a comment.
«Жемчужный» доступ к 1С: Предприятию 8.2