Откатить до версии хранилище 1с
Здравствуйте! Подскажите, а как можно удалить из хранилища то что не нужно обновлять? Один из разработчиков поместил в хранилище изменения для объекта, потом выяснилось что в рабочей базе это обновление не нужно применять. В рабочей базе данные из хранилища ещё не были получены.
Захватите объект, уберите изменения, снова поместите в хранилище.
Отмените захват объекта принудительно и поместите в хранилище объект из рабочей базы.
(2) Нельзя, это план счетов - в него сравнением-объединением добавили новые счета, а половина старых задвоилась и пометилась на удаление. это нельзя получать из хранилища, а то бухгалтерия четвертует и нас всех уволят нафиг))))
(4) Так и не получайте. У вас две базы, возьмите конфу из рабочей базы в тестовой захватите план счетов, объедините и замените на план счетов из файла и снова поместите в хранилище. Результатом буде план счетов в хранилище идентичный рабочей.
(1) А если просто поместить в хранилище объект из рабочей базы не захватывая? Прокатит? Сам не пробовал :-)
Выгружайте cfник из рабочей, захватывайте полностью все объекты на копии и загружайте цфник без сравнения-объединения. Потом все помещайте в хранилище обратно
Попробуйте открыть "История хранилища", выбрать версию до проблемных изменений и выполнить команду "Откатить до версии".
А можно как то удалить из хранилища, что бы вообще не получать эти объекты, как будто их там и не было? зачем все эти манипуляции
Если в хранилище конфигурации были опубликованы ненужные версии, конфигуратор предоставляет возможность отката до нужной версии хранилища. Для этого в списке версий нужно выбрать ту, до которой следует откатиться, и выбрать пункт Действия – Откатить до версии . На экран выводится вопрос-предупреждение: При выполнении отката информация об откатываемых версиях будет удалена без возможности восстановления. Продолжить? В случае утвердительного ответа будет произведен *, при котором из хранилища удаляются все версии, помещенные после указанной.
Преподаватель 1С
Санкт-Петербург
зарплата от 100 000 руб. до 120 000 руб.
Временный (на проект)
Можно ли вернуть хранилище, которое было до момента отката до более ранней версии этого хранилища?
И если да, то как это сделать?
коротко о том, что произошло:
1. захотел вернуть объект из хранилища до определенных изменений в этом объекте
2. зашел в историю хранилища, установил отбор по нужному мне объекту, выбрал версию "подходящую" для поставленной цели и выбрал "откатить до версии".
3. в результате "убил" месяц работы
Можно ли вернуться к тому хранилищу, которое было до отката до версии? И если "да", то как?
Достаточно начать, закончить тоже можно.Я за короткий срок так много сочинил,
Что много из того, что сочинил, уже забыл.
(К.Кинчев) fly --> fly
бекап базы?
в истории пропали изменения? SashaSh --> SashaSh
Можно вернуть состояние хранилища до момента отката если есть с чего возвращать.
Например с бэкапа конфигурации. Если такового нету, то необходимо создать cf-файл с базы какого-то другого пользователя хранилища,
который еще не успел обновиться с хранилища.
- Захватить конфигурацию в хранилище
- Меню "Конфигурация" -> "Сравнить объединить с конфигурацией из файла"
- Поместить в хранилище
Если во время отката были удалены объекты конфигурации, хранящие данные (например какой-то справочник), то вновь этот справочник добавиться, но без данных
(и также у пользователей, которые успели обновиться с хранилища)
Нет. Хотел вернуть только один документ до состояния без последних доработок, а получилось, что откатил всю конфигурацию
SashaSh @ Вчера, 20:26 ,
создать cf-файл с базы какого-то другого пользователя хранилища,
который еще не успел обновиться с хранилища.
- Захватить конфигурацию в хранилище
- Меню "Конфигурация" -> "Сравнить объединить с конфигурацией из файла"
- Поместить в хранилище
Сделали также. Спасибо
Достаточно начать, закончить тоже можно.Я за короткий срок так много сочинил,
Что много из того, что сочинил, уже забыл.
(К.Кинчев) Vladal --> Vladal
Ошибка в том, что надо было просто получить ту версию документа из хранилища.
А откат или сокращение до версии влияет на всю базу.
Если нет бекапов - ничего не сделать. Только вручную догонять изменения.
Я в свое время в скрипты бекапа баз добписал бекап хранилища и внешних файлов (фото, сканы и т.д.), прикрученных к базе.
Vladal --> Vladal
Итак, если осталась последняя конфигурация - может в бекапе базы, может еще как, то можно с ее помощью актуализировать конфигурацию хранилища.
Думаю, это можно взять из бекапа рабочей базы, который делается ежедневно.
1. Выгрузить актуальную конфигурацию в файл.
2. Сначала сравнить эту конфу с конфигурацией хранилища и захватить измененные объекты.
3. Затем сравнить и объединить изменения с конфигурацией из п.1 и поместить её в хранилище.
4. Настроить бекапы хранилища.
О принципе работы хранилища.
Каждая версия хранилища хранит только разницу в объектах от предыдущей версии.
Т.е. если подправили какую-то процедуру, то в хранилище помещается только текст модуля.
Когда откатили хранилище до более ранней версии, то "новые слои" были удалены.
п.3 создаст один единственный "слой" изменений над существующими.
Можно ли вернуть хранилище, которое было до момента отката до более ранней версии этого хранилища?
И если да, то как это сделать?
коротко о том, что произошло:
1. захотел вернуть объект из хранилища до определенных изменений в этом объекте
2. зашел в историю хранилища, установил отбор по нужному мне объекту, выбрал версию "подходящую" для поставленной цели и выбрал "откатить до версии".
3. в результате "убил" месяц работы
Можно ли вернуться к тому хранилищу, которое было до отката до версии? И если "да", то как?
Достаточно начать, закончить тоже можно.Я за короткий срок так много сочинил,
Что много из того, что сочинил, уже забыл.
(К.Кинчев) fly --> fly
бекап базы?
в истории пропали изменения? SashaSh --> SashaSh
Можно вернуть состояние хранилища до момента отката если есть с чего возвращать.
Например с бэкапа конфигурации. Если такового нету, то необходимо создать cf-файл с базы какого-то другого пользователя хранилища,
который еще не успел обновиться с хранилища.
- Захватить конфигурацию в хранилище
- Меню "Конфигурация" -> "Сравнить объединить с конфигурацией из файла"
- Поместить в хранилище
Если во время отката были удалены объекты конфигурации, хранящие данные (например какой-то справочник), то вновь этот справочник добавиться, но без данных
(и также у пользователей, которые успели обновиться с хранилища)
Нет. Хотел вернуть только один документ до состояния без последних доработок, а получилось, что откатил всю конфигурацию
SashaSh @ Вчера, 20:26 ,
создать cf-файл с базы какого-то другого пользователя хранилища,
который еще не успел обновиться с хранилища.
- Захватить конфигурацию в хранилище
- Меню "Конфигурация" -> "Сравнить объединить с конфигурацией из файла"
- Поместить в хранилище
Сделали также. Спасибо
Достаточно начать, закончить тоже можно.Я за короткий срок так много сочинил,
Что много из того, что сочинил, уже забыл.
(К.Кинчев) Vladal --> Vladal
Ошибка в том, что надо было просто получить ту версию документа из хранилища.
А откат или сокращение до версии влияет на всю базу.
Если нет бекапов - ничего не сделать. Только вручную догонять изменения.
Я в свое время в скрипты бекапа баз добписал бекап хранилища и внешних файлов (фото, сканы и т.д.), прикрученных к базе.
Vladal --> Vladal
Итак, если осталась последняя конфигурация - может в бекапе базы, может еще как, то можно с ее помощью актуализировать конфигурацию хранилища.
Думаю, это можно взять из бекапа рабочей базы, который делается ежедневно.
1. Выгрузить актуальную конфигурацию в файл.
2. Сначала сравнить эту конфу с конфигурацией хранилища и захватить измененные объекты.
3. Затем сравнить и объединить изменения с конфигурацией из п.1 и поместить её в хранилище.
4. Настроить бекапы хранилища.
О принципе работы хранилища.
Каждая версия хранилища хранит только разницу в объектах от предыдущей версии.
Т.е. если подправили какую-то процедуру, то в хранилище помещается только текст модуля.
Когда откатили хранилище до более ранней версии, то "новые слои" были удалены.
п.3 создаст один единственный "слой" изменений над существующими.
Каждый хочет держать под контролем свою жизнь, знать ответы на все вопросы. Так же дела обстоят в части информационных систем. Но здесь все значительно сложнее, так как ваша жизнь зависит от 3-10 человек. А в информационной системе зачастую работают 200 и 1000 сотрудников. И именно в таком потоке информации жизненно важно знать, что изменилось по сути и кто конкретно осуществил эти изменения.
Эту задачу давно ставили разработчикам 1C и вот, мы обрадованы появлением более или менее работающего механизма. Однако хранение версий в самой базе быстро приводит к ее росту. Устранению этого недостатка посвящена эта статья.
"
Версионирование 1С.
Механизм версионирования объектов используется для аудита изменений объектов информационной базы в разрезе времени и позволяет ответить на вопросы КТО, КОГДА и ЧТО изменил. В качестве версионируемых объектов могут выступать справочники и документы. Настройка механизма выполняется в форме настройки программы и доступна пользователю с ролью «Полные права». Настройка состоит из активизации механизма и настройки режима сбора версий документов и справочников.
Однако нет худа без добра. Со временем количество измененных записей по объему сопоставимо с основными данными, а потом попросту уходит в «отрыв» и превышает все разумные пределы. Что начинает существенно сказываться на объеме быстродействия системы.
Для устранения этого недостатка логично изымать эти данные и хранить их отдельно. Это тем более логично, когда информационных систем, которые необходимо подвергать аудиту, более чем одна.
Для решения этой задачи наша команда разработала программный продукт обладающий следующим функционалом:
1.Сбор данных об измененных объектах в фоновом режиме согласно расписанию. В рабочей базе остается только последнее изменение, количество «последних» регулируется. Так можно устранить «распухание» базы и одновременно можно в случае чего за секунду вернуть испорченный документ.
2.Формирование отчетов в части аудита (кто, что, когда изменил). Очень нравится «Безопасникам».
3.Все что когда либо менялось в системах.И все версии измененных объектов в одном месте в отдельной базе.Система собирает как версии так и журналы регистрации из указанных систем.
4. Но когда надо провести аудит изменений имеем полную картину.
В общем полезная система получилась. С одной стороны устраняет неопределенность изменений, а с другой дисциплинирует пользователей так как нет возможности свалить вину на «последнего».
Читайте также: