Свертка базы около 17 ГБ, поделитесь опытом соратники, пожалуйста
Есть переписанная вдоль и поперек база на ТиС 9.2 сейчас её размер
составляет около 16,8 Гб. Период работы с 01.01.2009 по сей день, плюс
ко всему есть, помеченные на удаление документы с 01.01.2006 по 01.01.2009
которые не возможно удалить не нарушив ссылочной целостности.
Необходимо обрезать базу до 01.01.2011.
Если у кого нибудь есть положительный опыт по свертке больших баз,
может какие-нибудь обработки по свертке универсальные есть, или хитрость какая-нибудь?
поделитесь опытом буду очень признателен
составляет около 16,8 Гб. Период работы с 01.01.2009 по сей день, плюс
ко всему есть, помеченные на удаление документы с 01.01.2006 по 01.01.2009
которые не возможно удалить не нарушив ссылочной целостности.
Необходимо обрезать базу до 01.01.2011.
Если у кого нибудь есть положительный опыт по свертке больших баз,
может какие-нибудь обработки по свертке универсальные есть, или хитрость какая-нибудь?
поделитесь опытом буду очень признателен
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Kuzya_brаtsk, Была тут обработка пользователя ildarovich, но но ее видимо снял... сворачивала любую ТиС за минуты. Опишу идею. Работало только на DBF версии. Обработка запускалась на базе и в новую папку копировала все DBF со справочниками, пропуская DBF регистров и документов, затем подключалась к базе и переносила остатки по всем регистрам. В результате ее работы получалась база с документами и остатками, которой а потом требовалось пройти тестирование и исправление и индексацию - работало реально минуты. Если свяжитесь, с пользователем ildarovich - думаю он поделится с Вами ...
Всё зависит только от того, нужна ли аналитика прошлых периодов или нет.
А так, в свертке нет ничего сложного - слепить доки ввода останков и прибить лишнее.
Проще прямым запросом кастрировать движуху регистра и таблички итогов, таким же способом проапдейтить табличку 1sjourn и избавиться от лишней периодики. Потом только пересчитать итоги и провести доки ввода останков. Ну и .. лишние элементы справочников можно тоже удалить (типа партий).
А так, в свертке нет ничего сложного - слепить доки ввода останков и прибить лишнее.
Проще прямым запросом кастрировать движуху регистра и таблички итогов, таким же способом проапдейтить табличку 1sjourn и избавиться от лишней периодики. Потом только пересчитать итоги и провести доки ввода останков. Ну и .. лишние элементы справочников можно тоже удалить (типа партий).
Да декствительно обработок тут много!
Сам занимался сворачиванием баз. НА одном предприятии сталкнулся такой вещью что падали ошибки
Как потом я выяснил вначе некотрое время учет велся по среднему, потом они перешли на ФИФО и в регистрах осталось видесь по несколькопеек, но без количества.
Для исправления этого написал обработку корая формирован по таким позициям документ инвентаризаии и правила суммы. после этого Свертка базы прошла на УРА
Сам занимался сворачиванием баз. НА одном предприятии сталкнулся такой вещью что падали ошибки
Как потом я выяснил вначе некотрое время учет велся по среднему, потом они перешли на ФИФО и в регистрах осталось видесь по несколькопеек, но без количества.
Для исправления этого написал обработку корая формирован по таким позициям документ инвентаризаии и правила суммы. после этого Свертка базы прошла на УРА
Сворачивал аналогичную базу. Не помню где нашел *.md. Алгоритм такой во вложении md в нем 2 документа "СверткаБазы" и "ВводНачальныхПериодическихЗначений" + обработка "ПутеводительСвертки".
1. Перед удалением документов необходимо установить ТА на первый документ. (так быстрее пометятся)
2. После пометки установить ТА на последний документ. (быстрее удалятся)
Плюсы: база за 4 года свернулась без потерь.
Минусы: в документ "СверткаБазы" тянет ссылки на документы помеченные на удаление
1. Перед удалением документов необходимо установить ТА на первый документ. (так быстрее пометятся)
2. После пометки установить ТА на последний документ. (быстрее удалятся)
Плюсы: база за 4 года свернулась без потерь.
Минусы: в документ "СверткаБазы" тянет ссылки на документы помеченные на удаление
Прикрепленные файлы:
1Cv7.MD
(13) Bear488,
Смысла нет одни минусы.
1. Сворачивание будет происходить в несколько раз медленней.
2. Если нет опыта работы с SQL. На приобретение этого опыта нужен не 1 месяц. Но даже наличие этого опыта не позволит сделать свертку быстрее и качественнее чем хорошо написанная универсальная обработка.
Смысла нет одни минусы.
1. Сворачивание будет происходить в несколько раз медленней.
2. Если нет опыта работы с SQL. На приобретение этого опыта нужен не 1 месяц. Но даже наличие этого опыта не позволит сделать свертку быстрее и качественнее чем хорошо написанная универсальная обработка.
(18) Kuzya_brаtsk, Повторюсь в базе остались объекты которые тянет документ "СверткаБазы". После пометки на удаление количество составило около 750000 тыс. объектов после непосредственного удаления помеченных на удаление осталось 230000.
Велся не корректный учет.
Велся не корректный учет.
Для того чтоб ускорить свертку могу посоветовать следующее.
Взять машину с процессором пошустрее. Больше чем двухядерного не нужно. Важно чтоб производительность 1 ядра была высокой.
Если оперативы 32gb или больше можно сделать рамдиск и сделать свертку на рамдиске.
Если оперативы меньше, можно заюзать SuperSpeed SuperCache.
Эта программулина организовывает в оперативе кэш для HDD. Может очень ускорить свертку.
Взять машину с процессором пошустрее. Больше чем двухядерного не нужно. Важно чтоб производительность 1 ядра была высокой.
Если оперативы 32gb или больше можно сделать рамдиск и сделать свертку на рамдиске.
Если оперативы меньше, можно заюзать SuperSpeed SuperCache.
Эта программулина организовывает в оперативе кэш для HDD. Может очень ускорить свертку.
(20) mar82,
Свертка не может выполняться в рабочем режиме.
Для свертки делаем копию базы, сворачиваем, проверяем, если все устраивает - ставим базу на место рабочей.
В транзакциях лучше.
Транзакции нужны исключительно для увеличения скорости.
Лучшее мерило длительности транзакции - время, а не количество объектов.
Я предпочитаю транзакции 2 - 10 секунд.
По-моему дает максимальный прирост в скорости.
Свертка не может выполняться в рабочем режиме.
Для свертки делаем копию базы, сворачиваем, проверяем, если все устраивает - ставим базу на место рабочей.
В транзакциях лучше.
Транзакции нужны исключительно для увеличения скорости.
Лучшее мерило длительности транзакции - время, а не количество объектов.
Я предпочитаю транзакции 2 - 10 секунд.
По-моему дает максимальный прирост в скорости.
Я бы проводил свертку в виртуальной памяти (программа RamDisc) - ну это при наличии большого количество ОЗУ у вас на сервере к примеру, или второй вариант хороший SSD диск.
+ Стандартные и не совсем обработки сверток здесь есть на ресурсе.
+ Стандартные и не совсем обработки сверток здесь есть на ресурсе.
Я это делал так:
Архив обработок прилагаю. Извините, что не пишу авторов, но моя только ПереносДанныхТП, остальное взято у разных авторов. И еще, я сворачивал не все регистры,а только 2 сильно разросшихся.
Выгрузить из СКЛ базу, закрыть ее от изменения.
Развернуть ДБФ копию, в ней добавить документ ОстаткиПоРегистру, создать документы с остатками по регистрам.
Снять еще одну копию, в ней провести альтернативную свертку обработкой Svertka.ert
Обработкой ЛишниеДоки.ert убирать документы работающие с регистрами.
Обработкой ПереносДанныхТП перенести документы с остатками и провести их.
Проверить остатки регистров на текущую дату обработкой SrReg.ert.
Выгрузить обрезанные данные и загрузить их в СКЛ.
Развернуть ДБФ копию, в ней добавить документ ОстаткиПоРегистру, создать документы с остатками по регистрам.
Снять еще одну копию, в ней провести альтернативную свертку обработкой Svertka.ert
Обработкой ЛишниеДоки.ert убирать документы работающие с регистрами.
Обработкой ПереносДанныхТП перенести документы с остатками и провести их.
Проверить остатки регистров на текущую дату обработкой SrReg.ert.
Выгрузить обрезанные данные и загрузить их в СКЛ.
Архив обработок прилагаю. Извините, что не пишу авторов, но моя только ПереносДанныхТП, остальное взято у разных авторов. И еще, я сворачивал не все регистры,а только 2 сильно разросшихся.
Прикрепленные файлы:
Свертка.rar
Я бы написал план действий и первым разделом плана был бы анализ базы. В зависимости от результатов решил, что делать, а уж потом - как делать и чем. Обычно самые проблемные регистры - партий и взаиморасчетов. Насколько они грязные?(минуса, "пересортица"). Надо ли сворачивать по организацияя (или даже убрать какие-то организации). Определил, можно ли "вешать" остатки по товарам и расчетам на один документ контрагента. Кстати, сам чистку регистров делал на FoxPro (гораздо быстрее), а ТА ставил на дату ввода остатков (чтобы ускорить работу).
Кстати, может не стоит сворачивать, а потратить силы и средства для перехода на 8-ку?
Кстати, может не стоит сворачивать, а потратить силы и средства для перехода на 8-ку?
Необходимо обрезать базу до 01.01.2011.
...и в ней же еще есть документы по сей день... как бы не изворачиваться но чтоб не поломать ссылочной целостности прийдется после свертки практически любой обработкой в документах ввода остатков заменить ссылки источников остатков на ссылку на сам документ ввода остатков, после этого пометить доки на удаление до даты ввода остатков(есть куча методов описаны ранее) и самое грустное это потом перепровести доки (восстановить последовательность) вот только после этого можно удалить доки помеченные на удаление не нарушив ссылочной целостности ... но 16 гиг печальнонадо на серваке крутить...
Только не ругайтесь. Сам не пробовал, опыта не хватает.
Очень хотел разобраться с сворачиванием базы 1С77, много в форуме прочитал и потратил времени на сам процесс сворачивания стандартными средствами.
Посмотрите вот это, вдруг поможет.
Здесь на форуме тоже где-то была эта информация, не смог найти.
Методика быстрого сворачивания периода больших баз в системе 1С:Предприятие 7.7
Библиотека ToySQL — Продукты для оптимизации 1С
Dmitr033, скажите что такое СКЛ? Вопрос снят, я понял - это SQL.
zels, поделитесь методикой, у меня самые проблемные регистры - партий и взаиморасчетов, плз..
Чтобы не засорять ветку можно через "Окно диалогов". Спасибо.
Очень хотел разобраться с сворачиванием базы 1С77, много в форуме прочитал и потратил времени на сам процесс сворачивания стандартными средствами.
Посмотрите вот это, вдруг поможет.
Здесь на форуме тоже где-то была эта информация, не смог найти.
Методика быстрого сворачивания периода больших баз в системе 1С:Предприятие 7.7
Библиотека ToySQL — Продукты для оптимизации 1С
Dmitr033, скажите что такое СКЛ? Вопрос снят, я понял - это SQL.
zels, поделитесь методикой, у меня самые проблемные регистры - партий и взаиморасчетов, плз..
Чтобы не засорять ветку можно через "Окно диалогов". Спасибо.
Прикрепленные файлы:
my_wrap.zip
my_clear.zip
ToySQL_Test.rar
ToySQL2_UsersGuide.rar
loader.zip
(34) validat, у меня нет методики (в печатном виде, во всяком разе).
Зато есть определенный опыт. Сворачивание больших баз - это поиск компромисса между тем, что хочет заказчик, что ему надо, что есть в базе и во что это выльется по времени и деньгам.
Сначала анализ, потом "причесывание" критичных регистров. Создается документ "ФиксацияОстатков", который может двинуть любой регистр. В шапке указывается, какой именно регистр надо фиксировать. При заполнении документа (заполнение делает сам документ или обработка) рассчитываются остатки на дату документа (день перед датой свертки), сворачиваются по согласованному с заказчиком алгоритму и запоминаются в табличной части документа. Так что сотня записей о задолженности контрагента (пример из практики) может свернуться до одной. Ссылки на различные партии тоже сворачиваются (как вариант - сворачиваются ссылки на старые партии). Иногда в качестве партий можно использовать сами документы фиксации остатков, иногда нельзя и тогда генерируются новые документы прихода/расхода (почти пустые, только организация, контрагент, договор). При проведении документ фиксации делает расчет остатков и выполняют корректирующие движения так, чтоб выйти на остатки в табличной части.
Когда документы для всех регистров заполнены, можно из файлов регистров удалить движения и остатки до даты свертки (надо знать структуру файлов, я использовал FoxPro). Затем удаляются старые неиспользуемые партии (к ним нет привязанных движений) обработкой 1С или опять же FoxPro. Наконец, перепроводятся документы фиксации и документы после даты свертки. Могут быть проблемы при проведении, т.к. другие документы не знают про "фиксацию остатков", но это не самая сложное.
В результате до даты свертки нет проведенных документов, кроме "фиксация остатков", хотя могут быть непроведенные документы-партии (я их генерирую днем раньше, чем фиксация остатков).
Вот как-то так (конечно, это не полная картина, скорее набросок).
Зато есть определенный опыт. Сворачивание больших баз - это поиск компромисса между тем, что хочет заказчик, что ему надо, что есть в базе и во что это выльется по времени и деньгам.
Сначала анализ, потом "причесывание" критичных регистров. Создается документ "ФиксацияОстатков", который может двинуть любой регистр. В шапке указывается, какой именно регистр надо фиксировать. При заполнении документа (заполнение делает сам документ или обработка) рассчитываются остатки на дату документа (день перед датой свертки), сворачиваются по согласованному с заказчиком алгоритму и запоминаются в табличной части документа. Так что сотня записей о задолженности контрагента (пример из практики) может свернуться до одной. Ссылки на различные партии тоже сворачиваются (как вариант - сворачиваются ссылки на старые партии). Иногда в качестве партий можно использовать сами документы фиксации остатков, иногда нельзя и тогда генерируются новые документы прихода/расхода (почти пустые, только организация, контрагент, договор). При проведении документ фиксации делает расчет остатков и выполняют корректирующие движения так, чтоб выйти на остатки в табличной части.
Когда документы для всех регистров заполнены, можно из файлов регистров удалить движения и остатки до даты свертки (надо знать структуру файлов, я использовал FoxPro). Затем удаляются старые неиспользуемые партии (к ним нет привязанных движений) обработкой 1С или опять же FoxPro. Наконец, перепроводятся документы фиксации и документы после даты свертки. Могут быть проблемы при проведении, т.к. другие документы не знают про "фиксацию остатков", но это не самая сложное.
В результате до даты свертки нет проведенных документов, кроме "фиксация остатков", хотя могут быть непроведенные документы-партии (я их генерирую днем раньше, чем фиксация остатков).
Вот как-то так (конечно, это не полная картина, скорее набросок).
до резки очень желательно поиграть на копии и посмотреть на время выполнения операций,
как вариант, резать частями,
создали доки остатков на конец 31.12.2006,
сняли с проведения доки за 2006 год,
провели остатки
зафиксировали время и т.д.
помечать на удаление документов предыдущих периодов можно и в другое время, когда есть возможность.
на большой базе как-то приходилось по выходным резать такими короткими кусками,
для того, чтобы в случае чего подсовывать в понедельник "недорезку",
в следующие выходные следующую партию
из личных наблюдений:
без транзакций отрабатывало быстрее, чем меньше период ставишь в обработке тем быстрее отрабатывает год, т.е. быстрее каждый квартал запускать по отдельности, чем сразу год целиком
я пользовалась для DBF на 77 обработкой для переноса остатков во вложении и обычной универсальной обработкой документов для снятия пометки на удаление и самой пометки на удаление
как вариант, резать частями,
создали доки остатков на конец 31.12.2006,
сняли с проведения доки за 2006 год,
провели остатки
зафиксировали время и т.д.
помечать на удаление документов предыдущих периодов можно и в другое время, когда есть возможность.
на большой базе как-то приходилось по выходным резать такими короткими кусками,
для того, чтобы в случае чего подсовывать в понедельник "недорезку",
в следующие выходные следующую партию
из личных наблюдений:
без транзакций отрабатывало быстрее, чем меньше период ставишь в обработке тем быстрее отрабатывает год, т.е. быстрее каждый квартал запускать по отдельности, чем сразу год целиком
я пользовалась для DBF на 77 обработкой для переноса остатков во вложении и обычной универсальной обработкой документов для снятия пометки на удаление и самой пометки на удаление
Прикрепленные файлы:
Perenos_ostatkov.ert
(36) pt_olga,
А можете сказать точнее что значит: "без транзакций отрабатывало быстрее"?
Может быть без одной транзакции?
Обычно в свертках можно встретить режим "все в одной транзакции" и не припомню режима наподобие:
"транзакциями по 5 секунд".
На больших базах свертка одной транзакцией, может быть в десятки раз медленнее. И часто транзакция в принципе не завершается - 1с вылетает.
Ускорение дают только короткие транзакции по несколько секунд.
Причем чем меньше длительность одной операции (пометки на удаление объекта) тем больше прирост скорости.
А можете сказать точнее что значит: "без транзакций отрабатывало быстрее"?
Может быть без одной транзакции?
Обычно в свертках можно встретить режим "все в одной транзакции" и не припомню режима наподобие:
"транзакциями по 5 секунд".
На больших базах свертка одной транзакцией, может быть в десятки раз медленнее. И часто транзакция в принципе не завершается - 1с вылетает.
Ускорение дают только короткие транзакции по несколько секунд.
Причем чем меньше длительность одной операции (пометки на удаление объекта) тем больше прирост скорости.
(37) an_2, на сколько я разбираюсь в апельсинах, транзакции в принципе позволяют сохранить целостность данных и исключить/уменьшить работу с "грязными" данными, в случае резки базы в монопольном режиме поднимать транзакцию особого смысла не вижу и империческим путем вышла на то, что групповая обработка документов быстрее крутиться без объявления начала и соответственно конца транзакции
как-то так
как-то так
(38) pt_olga,
Обработка любытная. Понравилась. :)
Про транзакции:
Шла речь про скорость. Поэтому я и написал про скорость.
Написал собственно то что есть на самом деле: короткие транзакции на dbf могут давать очень большой прирост скорости, длинные не дают и могут приводить к вылетам.
Это, можно сказать, побочный продукт использования транзакций.
А назначение транзакций здесь нипричем.
Обработка любытная. Понравилась. :)
Про транзакции:
Шла речь про скорость. Поэтому я и написал про скорость.
Написал собственно то что есть на самом деле: короткие транзакции на dbf могут давать очень большой прирост скорости, длинные не дают и могут приводить к вылетам.
Это, можно сказать, побочный продукт использования транзакций.
А назначение транзакций здесь нипричем.
(44) validat, попробывал свертку
Попытался обрезать базу на полгода, т.е. с 01.01.2009 по 01.07.2009
обработку запустил 01.06.2013 20:00 сегодня 03.06.2013 9:00 пришлось прервать (т.к. делал на сервере думал что
за выходные успею), нехватило оперативы (6 Гб стоит), Жесткий SSD, проц: intel i7, ОС: Windows Server 2008.
Выполнение обработки (шел процесс пометки на удаление документов) прервал жестко - просто убил процесс 1с7.7 в диспетчере задач. Теперь делаю тестирование исправление базы через конфигуратор, т.к. она не открывается. Хочу посмотреть, за какой период док-ты пометелись на удаление.
Кстати, был нюанс - Немного пришлось переделать конфигурацию свертки, в документах "СверткаБазы", "Операция", "ВводНачальныхПериодическихЗначений" стандартный реквизит "Номер" тип поставил "текстовый", т.к. когда стоял числовой вовремя записи этих документов программа постоянно вылетает и Винда выдает ошибку - где тут связь сам не могу понять.
Выгрузку-загрузку не делал (может быть и зря), т.к. не известно насколько процесс может затянуться.
Попытался обрезать базу на полгода, т.е. с 01.01.2009 по 01.07.2009
обработку запустил 01.06.2013 20:00 сегодня 03.06.2013 9:00 пришлось прервать (т.к. делал на сервере думал что
за выходные успею), нехватило оперативы (6 Гб стоит), Жесткий SSD, проц: intel i7, ОС: Windows Server 2008.
Выполнение обработки (шел процесс пометки на удаление документов) прервал жестко - просто убил процесс 1с7.7 в диспетчере задач. Теперь делаю тестирование исправление базы через конфигуратор, т.к. она не открывается. Хочу посмотреть, за какой период док-ты пометелись на удаление.
Кстати, был нюанс - Немного пришлось переделать конфигурацию свертки, в документах "СверткаБазы", "Операция", "ВводНачальныхПериодическихЗначений" стандартный реквизит "Номер" тип поставил "текстовый", т.к. когда стоял числовой вовремя записи этих документов программа постоянно вылетает и Винда выдает ошибку - где тут связь сам не могу понять.
Выгрузку-загрузку не делал (может быть и зря), т.к. не известно насколько процесс может затянуться.
Возможны 2 варианта, если не работает свертка - это проблемы с самой базой данных (пробуем тестировать и исправлять), либо упираетесь в ограничение 1С на 10 000 строк в документе. попробуйте отдельно свернуть проводки и отдельно регистры.
(81)Спасибо теперь понятно, только в чем разница если я это могу и в самой 1С сделать - удалить документы за определенный период хоть с сохранением ссылочной целостности, хоть совсем. Да и опыта работы с прямыми запросами у меня нет, максимум это запросы на 1с 8.2, т.е. с другими СУБД кроме как 1с я не работал.Или я опять не так понял?
(95) Ёпрст, Если не секрет, какие характеристики компьютера? У меня комп пятилетней давности. База тоже комплексная была. Размер 12 ГБ. Время переиндексации 30 мин. (программно, штатно - 45), Свертка - 55 мин. Создание док. остатков - 30 мин. (20 из них на бухучет). Проведение 4 мин. Соотнести производительность можно по времени индексирования. 20%-25% свертки занимает работа с периодическими реквизитами. Примерно как-то так. Для штатной свертки - самый затратный пункт - пометка док-ов на удаление. Где-то 10-15 тыс. документов в час.
(83) Kuzya_brаtsk,
Разница в следующем:
Прямыми запросами ты напрямую управляешь данными минуя движок 1с.
Это позволяет например удалять документы, движения, итоги регистров, немеряно раз быстрее.
Для этого нужно:
1. Знание SQL языка (работа с dbf выполняется на этом же языке).
2. Знание таблиц 1С. То есть нужно точно знать какие данные в каких таблицах и КАК хранятся.
Разница в следующем:
Прямыми запросами ты напрямую управляешь данными минуя движок 1с.
Это позволяет например удалять документы, движения, итоги регистров, немеряно раз быстрее.
Для этого нужно:
1. Знание SQL языка (работа с dbf выполняется на этом же языке).
2. Знание таблиц 1С. То есть нужно точно знать какие данные в каких таблицах и КАК хранятся.
У меня у самого был случай свертки базы данных весом в 13 гб (торговля 7.7),при обычно свертке мало того что это долго по времени так еще и ошибку выдавала что мало оперативной памяти, ладно думаю поставил windows7 64bit, и 4 гб оперативы, прошло около суток программа сворачивалась 3 суток и опять же выдала ошибку мало оперативы, после чего взял комп на i5 проце, поставил 8gb оперативы, взял 2HDD поставил их в страйп(для улудшения скорости чтения и записи с харда), поставил 64bit систему, и прошло буквально 12ч. как база данных у меня свернулась.
Для решения проблемы вам нужен сервер 64-х битный обязательно и SQL 64-х битный.
Не бойтесь развернуть базу на SQL, это очень просто. Примеров в сети масса, по шагам все повторите и все.
Это займет у вас намного меньше времени и будет гарантированный результат, к тому же и новые полезные знания.
Не бойтесь развернуть базу на SQL, это очень просто. Примеров в сети масса, по шагам все повторите и все.
Это займет у вас намного меньше времени и будет гарантированный результат, к тому же и новые полезные знания.
Я в прошлом году пользовался обработкой, указанной автором в 3-м посте. Но, кажется, немного ее допилил. Сворачивал базу Торговля для Украины 3 ГБ. Делал в несколько этапов. Сначала устанавливал точку последовательности на последний документ дня ДатаСвертки - 1 и бухгалтерские итоги, если они есть, на тот же квартал. В данном случае на последний документ 31.12.2010 и 4 квартал 2010. Потом выполнял 1-3 этапы обработки. Далее, не закрывая обработку, переносил точку последовательности на первый документ в базе (если используется компонента Бухгалтерия - то и бухгалтерские итоги на квартал, предшествующий первому документу в базе). А тогда п. 4-6 обработки. На полное тестирование базы и последующей сверткой и уделением помеченных документов ушло часов 6 на рабочем ноутбуке. Использовал правда патченую dbeng32.dll (реально ускоряет работу с диском). Ну и пару приемов для ускорения тестирования базы. Ну и перед перед этим посидел над обработкой, а то она вроде как бы зависала.
Была написана обработка свертка базы для ресторана: Астор:Торговый дом
в принципе свертка это простой процесс, нужно учесть, чтобы пользователи в старый период не могли заходить, чтобы случайно не перепровели документы и не создали движения.
потом необходимо настроить какие регистры планируется сворачивать.
Свертка формирует документ с необходимыми движениями по регистрам.
После того, как остатки сформированы (движения сперва формируются с активностью=ложь)
обрабатываем документ и очищаем все указанные в настройках движения.
после очистки активность=истина
и фиксируем транзакцию.
и переносим границы последовательностей
в принципе свертка это простой процесс, нужно учесть, чтобы пользователи в старый период не могли заходить, чтобы случайно не перепровели документы и не создали движения.
потом необходимо настроить какие регистры планируется сворачивать.
Свертка формирует документ с необходимыми движениями по регистрам.
После того, как остатки сформированы (движения сперва формируются с активностью=ложь)
обрабатываем документ и очищаем все указанные в настройках движения.
после очистки активность=истина
и фиксируем транзакцию.
и переносим границы последовательностей
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот