Comments 39
может имеет смысл обновить статью относительно того как это всё работает с 8.3?
Такое ощущение что люди придумывают, а для чего бы еще написать скрипт. Распишу по пунктам:
1. Чистить кэш после каждого выхода это просто жесть, пользователь настраивает программу для удобной работы, а вы эти настройки каждый день сбиваете.
2. Ни разу не пришлось исправлять ошибки таким способом, при нем разрушается целостность базы и не факт что это не вылезет боком позже. На этот случаю и существуют бэкапы.
3. Спасибо за скрипт, можно придумать применение.
4. Как часто нужно добавлять новых пользователей в базу? По своему опыту, в бухгалтерии текучка небольшая, для оного пользователя в год скрипт ненужен.
5.Как часто нужно таскать базы между серверами? Это рутинная задача только тогда когда один человек обслуживает сотни баз 1с.
1. Чистить кэш после каждого выхода это просто жесть, пользователь настраивает программу для удобной работы, а вы эти настройки каждый день сбиваете.
2. Ни разу не пришлось исправлять ошибки таким способом, при нем разрушается целостность базы и не факт что это не вылезет боком позже. На этот случаю и существуют бэкапы.
3. Спасибо за скрипт, можно придумать применение.
4. Как часто нужно добавлять новых пользователей в базу? По своему опыту, в бухгалтерии текучка небольшая, для оного пользователя в год скрипт ненужен.
5.Как часто нужно таскать базы между серверами? Это рутинная задача только тогда когда один человек обслуживает сотни баз 1с.
отвечу по пунктам:)
1. далеко не все настройки хранятся в кэше. + представьте две сотни файловых баз, каждая из которых регулярно обновляется, причем самими пользователями.
2. об этом и есть предупреждение. опять же, представьте РИБ c файловыми базами в магазинах. бэкап файловой базы — это отдельная песня (а необходимо держать и архив бэкапов), выгрузка нового образа занимает время, а проверка на физ. целостность занимает полчаса от силы — и в 95% случаев магазин может торговать. да и в случае повреждения документов можно перепровести их в центральном узле.
4. пример приведен для бухгалтерии, доработать можно и до любой другой конфигурации. а на счет текучки… контора на контору не приходится:)
5. да, всё верно. или когда сотню баз нужно разово перенести — написать скрипт быстрее, чем руками:)
1. далеко не все настройки хранятся в кэше. + представьте две сотни файловых баз, каждая из которых регулярно обновляется, причем самими пользователями.
2. об этом и есть предупреждение. опять же, представьте РИБ c файловыми базами в магазинах. бэкап файловой базы — это отдельная песня (а необходимо держать и архив бэкапов), выгрузка нового образа занимает время, а проверка на физ. целостность занимает полчаса от силы — и в 95% случаев магазин может торговать. да и в случае повреждения документов можно перепровести их в центральном узле.
4. пример приведен для бухгалтерии, доработать можно и до любой другой конфигурации. а на счет текучки… контора на контору не приходится:)
5. да, всё верно. или когда сотню баз нужно разово перенести — написать скрипт быстрее, чем руками:)
А что такого отдельного в бэкапе файловой базы?! Более простой операции, чем копирование 1 (одного) файла сложно себе представить. И уж там создавайте истории как душе угодно.
вам нужно чтоб она была закрыта. использование vss при копировании (я так делаю) ситуацию спасает, но не до конца — есть шанс получить битую базу за счёт копирования снапшота, сделанного в момент записи.
единственный православный вариант бэкапа файловой базы — выгрузка в .dt. Ну или хотя бы гарантировать отсутствие рабочих процессов в базе. оба варианта не всегда реальны (отключение электричества в нерабочие часы).
единственный православный вариант бэкапа файловой базы — выгрузка в .dt. Ну или хотя бы гарантировать отсутствие рабочих процессов в базе. оба варианта не всегда реальны (отключение электричества в нерабочие часы).
Выгрузка в .dt не является бэкапом от слова «совсем» (об этом даже в платформенной документации написано). Плюс для такого «бэкапа» точно так же нужно отсутствие пользователей в базе.
Поэтому единственно надежным вариантом бэкапа файловой базы является копирование файла базы данных.
Поэтому единственно надежным вариантом бэкапа файловой базы является копирование файла базы данных.
на эту тему много копий сломано, можно ли бэкапить выгрузкой, спорить не буду. 1С не рекомендует, поскольку не может гарантировать, что dt-шка загрузится обратно.
на моей практике проблемы были только при бэкапе уже битой базы или если пытаться выгрузить базу, где размер какой-нибудь таблицы больше 4гб.
на моей практике проблемы были только при бэкапе уже битой базы или если пытаться выгрузить базу, где размер какой-нибудь таблицы больше 4гб.
Каждый выбирает для себя :)
Случаев, когда база не загружалась из выгрузки — овер много.
Но если вы продолжаете не верить настоятельным рекомендациям вендора — каждый выбирает для себя :)
Случаев, когда база не загружалась из выгрузки — овер много.
Но если вы продолжаете не верить настоятельным рекомендациям вендора — каждый выбирает для себя :)
согласен. как я уже писал, я не могу позволить себе монопольный доступ к базе… поэтому где нужно бэкапить — я копирую с vss-снапшота. на озвученных точках бэкапить очень хочется, но было не реально — и монопольного доступа не получить, и железо дряхлое и тухлое. поэтому и chdbfl в обёртке.
в последствии там переехали на мини-сервачки с линуксом и постгре.
в последствии там переехали на мини-сервачки с линуксом и постгре.
Начиная с 8.3.7 при выгрузке идет проверка целостности.
Рекомендации от этого не меняются.
Рекомендации может и не меняются, но вероятность загрузки из dt значительно выше. Я у себя каждую ночь делаю выгрузку в dt и дамп sql, своей же тулзой на том же AutoIT. Если выгрузка не прошла за отведенное количество попыток, то алерт на мыло предупредит, что что-то не так, и дальше можно по логам смотреть, база это побилась или какое соединение висит.
«вероятность загрузки из dt значительно выше» — по сравнению с чем?
вероятность загрузки из dt значительно выше
Для данных будет спокойнее, если так считать перестать :) Но это мое личное мнение и я его не навязываю :)
В типовых решениях на 8.3 встроена система резервного копирования.
Укажите путь и план работы. Сама заблокирует базу, выгонет пользователей (в том числе в файловой версии), сделает бэкап 1C.CD запакованного в zip и разблокируется. Для файловых либо должен быть активный сеанс ночью (особенность регламентных заданий в файловой) либо можно настроить предложение сделать бэкап при завершении сеанса администратора.
Всему можно найти применение. Кроме заведения пользователей на конфигурациях с БСП — группы доступа всё равно назначать в самой 1С.
Вот это вы меня удивили, пользователи сами себе обновляют базы. Тогда понятно зачем вам все эти скрипты. Как по мне это просто костыли из-за нежелания увеличивать расходы на содержание компьютерной техники. На текущем месте работы все настроено через стандартные механизмы обмена 1с, за несколько год только раз возникла проблема с профилем пользователя. Правда в нас все более по взрослому, все базы крутятся на mssql.
ответ для avelor
ответ для avelor
не, как было написано — когда обычный клиент с 2-4 базами всякие затейства не нужны (ну максимум — заведение пользователей и какие-нибудь хитрые регламентные задачи). Но вот у меня был клиент — бухгалтерский аутсорс, пара сотен файловых баз и сотня скулёвых. согласовать с пользователями регулярные обновления конфигураций в автоматическом режиме не реально, руками обновлять — свихнёшься, но сами пользователи вполне бодро обновляют базы (в том числе и скулевые), как через конфигуратор, так и через предприятие. так же как и классификаторы:) тут правда пришлось повозится с SRP и нагородить ещё костылей (грёбаный bnk.exe!), но это уже детали.
Я бы добавил еще одну «маленькую» отверточку http://infostart.ru/public/15126/
Да, это отличная вещь!
Вот-вот. Эдакий «мультитул» даже, а не маленькая отверточка! Уже не первый год пользуюсь, и поминаю автора добрым словом! Только я бы добавил ссылку напрямую на сайт автора, т.к. там доступен инструмент без наличия startmoney.
Самобытьненько. Иногда, конечно, такие решения лучше чем ничего.
Но на всю статью одна строчка Powershell. Надеялся на большее.
А еще системные администраторы НЕ должны создавать пользователей в базах 1С. Это должен или владелец базы делать, или обслуживающий ее специалист по 1С. Это правильно с точки зрения разделения ответственности и безопасности.
Но на всю статью одна строчка Powershell. Надеялся на большее.
А еще системные администраторы НЕ должны создавать пользователей в базах 1С. Это должен или владелец базы делать, или обслуживающий ее специалист по 1С. Это правильно с точки зрения разделения ответственности и безопасности.
обслуживающий ее специалист по 1С
в моей практике хорошие 1с-специалисты бежали от такой рутины как от огня, а плохих… лучше не брать вовсе :) Это как заставить ведущего сисадмина, короля Active Directory, заводить в ней пользователей. другое дело, что структура пользователей и групп должна быть чёткой, а не сотня дополнительных свойств и хардкода имён пользователей в обработках.
Хорошая тема создавать пользователей отделу кадров, при приёме на работу. сразу и в 1с, и в AD (автоматически). но такое может привести к безумию в наших реалиях =(
Если честно, не вижу никакой проблемы том, что скиллованные 1Сники создают пользователей. Вопрос лишь в объемах. Один в день и сотня в день это разные вещи. И тратить время квалифицированного специалиста на такие вещи нерационально, а ему и не интересно. Я не интересовался у 1Сников, автоматизируется ли этот процесс.
А вот что касаемо до AD, то массовые заведения учеток делаются через синхронизацию с учетной системой, либо по отдельной выгрузке. А пару-тройку руками создать могу и я, не вижу ничего зазорного, хотя AD леса в том или ином виде в веденье моей группы. Структура организационных подразделений в AD всегда должна повторять штатную расстановку в учетной системе в контексте сотрудников.
У нас кадровая служба не создает ни 1Сные, ни АДшные учетки, они могут только подать заявку на создание учетной записи в сервисдеск. В некоторых организациях у нас это реализовано доп обработками, когда кадровик только выбирает обработку, а письмо со всей необходимой инфой улетает куда нужно само.
А вот что касаемо до AD, то массовые заведения учеток делаются через синхронизацию с учетной системой, либо по отдельной выгрузке. А пару-тройку руками создать могу и я, не вижу ничего зазорного, хотя AD леса в том или ином виде в веденье моей группы. Структура организационных подразделений в AD всегда должна повторять штатную расстановку в учетной системе в контексте сотрудников.
У нас кадровая служба не создает ни 1Сные, ни АДшные учетки, они могут только подать заявку на создание учетной записи в сервисдеск. В некоторых организациях у нас это реализовано доп обработками, когда кадровик только выбирает обработку, а письмо со всей необходимой инфой улетает куда нужно само.
кровь из глаз от ваших костылей
вы читали руководство администратора?
плохой стиль написания, без конкретных примеров…
что за мистика?
в %appdata% хранятся а дальше по конкретной версии платформы
на чем у вас скрипты?? инструменты администратора 1с это vbs и прочие bat'ники
вы читали руководство администратора?
плохой стиль написания, без конкретных примеров…
Эти данные хранятся в профиле пользователя, в папках с длинными названиями из GUID баз данных.
что за мистика?
в %appdata% хранятся а дальше по конкретной версии платформы
на чем у вас скрипты?? инструменты администратора 1с это vbs и прочие bat'ники
Спасибо за статью. хотелось бы еще спросить можно ли автоматом накатывать обновления из cf файлов. по поводу чистки кеша — расхожие мнения, я включаю очистку только перед обновлением конфигурации.
если база на поддержке — то штатным механизмом (запуск с ключом /UpdateCfg). вообще штатный механизм обновления из предприятия типовых баз весьма неплох — скачивается .hta файл, оттуда ком-соединениями управляется база (выгоняются пользователи. делается бэкап, последовательно применяются нужные .cf). или вы имеете ввиду обновление нетиповых\снятых с поддержки баз?
с типовой конфигурацией все в принципе понятно, а вот со снятой с поддержки возникает затруднение…
можно намутить свою поставку обновления а-ля штатная — https://its.1c.ru/db/metod8dev#content:4727:hdoc
Ещё 2 отвёртки в набор стар.пирата.
1) для работы с файловыми базами: переносной (portable) сcleaner+winapp2.ini+программа Auslogics disk defrag. Просто скопированная папка ранее установленного A.d.d. с офиц.сайта, но с меньшим кол-вом спама, чем в инсталляторе.
Лучше день 20 минут на ccleaner+defrag потерять — потом за час долететь обновить.
Заодно и SMART параметры НЖМД глянуть, если это не RAID.
Вдруг он (HDD) уже помирает и температурит, а обновления его добьют или бэкапы на том же диске окажутся битыми.
2) сборники обработок infostart_mega и т.п. с торрентов.
подскажите как в PS завершить все процессы 1Сv8.exe для определенного пользователя ?
Напрямую никак, только используя WMI:
$ProcessNameToTerminate = "OneDrive"
$ProcessUsernameToTerminate = "User"
$ProcessOwner = @{}
gwmi win32_process |% {$ProcessOwner[$_.handle] = $_.getowner().user}
get-process | select processname,Id,@{l="Owner";e={$ProcessOwner[$_.id.tostring()]}} | ? {($_.ProcessName -eq $ProcessNameToTerminate) -and ($_.Owner -eq $ProcessUsernameToTerminate)} | Stop-Process -Force -Confirm:$false -VerboseSign up to leave a comment.
Набор отверток администратора 1С