Ускоренное проведение большого объема документов в 1С V7 sql #502838

Необходимо в копии базы (предварительно) провести доки с начала года до текущей даты (бухи хотят посмотреть как внесенные изменения в начале года отразятся на отчетах). Конфа самописная, ГП не используется, в документах реализации идет списание по регистру остатко и по партиям (реализация товаров на оптовом центре). Объем документов достаточно большой порядка 300-700 за день , строк в документах 100-500. Есть самописная процедура (с использованием ReconnectNative) для проведения документов реализации - если проходили изменения в партиях прошедшей датой. Но даже с использованием процедуры ReconnectNative - проведение документов за такой период займет несколько дней. Причем если я провожу 1 месяц (предыдущий) - это занимает - примерно 4 часа, а если 3 месяца то время проведения будет гораздо больше 3*4, т.е. с увеличением периода возрастает в прогрессии. Все документы с начала и до конца проводятся одинаково медленнее. Когда -то мне попадались статьи - как ускорить проведение документов (при обработке большого периода), но сейчас найти не могу. На сколько я помню там были какие-то финты с ТА (и еще что-то), но деталей вспомнить не могу.

переписать модули проведения.

конфа-то какая? sql 2000 или 2005? проводится я так понял обработкой без сдвига ТА?

увидел - самописная. тогда +1 к за деньги могу сделать. будете потом в рабочей базе использовать.

sql 2000, можно про сдвиг ТА поподробнее

+ перед перепроведение передвинуть ТА на начало года? и двигать ТА вместе с документами ?

да, чтоб документ всегда в ТА проводился. Но лучше .

ну если проводить задним числом - медленней будет проводится чем на ТА. но для этого надо проводить системным проведением или спец обработкой, которая ТА будет сдвигать. без оптимизации (переписать модули) в этом случае со временем будет замедление. хотя может попроботвать проведение на ТА и реконнект. может получше станет.

вообще конфу надо смотреть. может у вас там вообще расчет итогово не используется. тогда оптимизация не поможет. но тогда не ясно почему со временем замедляется...

в моей обработке перепроведения все документ реализации предварительно делались непроведенными, а уже потом только проводились. В случае со сдвигом ТА - нужно ли доки предварительно распроводить?

Делай из SQL файловую ставь на самую мощную машину и проводи через Операции->Проведение документов… будет в разы быстрее чем на SQL.

сие невозможно, текущий размер базы = 33 гига (за 5 лет)

в случае со сдвигом ТА не надо отменять проведение.

Аналогично многократно описанному "восстановлению последовательности с использованием ReconnectNative"

Если срочно, то Операции->Проведение документов… и периодически выходи из базы (например помесячно проводи или понедельно). Получишь и сдвиг ТА и аналог ReconectNative Если есть время - перепиши модули проведения

Спасибо всем, буду пробовать

у СКЛ2000 с групповым/последовательным проведением документов - весьма неприятная проблема (засирание временных таблиц и ОЧЕНЬ сильное замедление).

решается при помощи  ReconnectNative (есть и другие решения, но уже в большинстве платные)

"хотя может попроботвать проведение на ТА и реконнект. может получше станет" - заметно быстрее

народ писал что с переходом на 2005 - и реконект не нужен и проводится гораздо быстрее. а с 2008 - еще быыстрее.. может на врем япроведения попробовать свежие скули...?

если самописка написано правильно более-менее, то за сутки проведется чуть больше 2-х месяцев... что можно подумать? сделать временную "дописку" и перепроводить только по тем регистрам, на которые влияет изменение...

если же самописка написана с расчетом ВременныхИтогов, то со сдвигом ТА получится ускорение весьма существенное, можно сказать - на порядок. тогда вся база перепроведеться возможно в районе суток-двое...

одно время думал переходить на 2005 скуль, не из-за реконекта, а из-за ограниченности 2000-го в плане использования памяти . Дополнили память до 16 , а было 4 гига, (сейчас не помню деталей )включали доболнительные режимы, что бы скуль увидел весь объем  - вроде PAE и еще что-то, но быстрее не стало. Пишут что 2005 (64 битный) правильно использует память. Да только далеко не все то, что работало на 2000-м заработает и на 2005 (хотя вроде как все повравимо, но я так и не решился). Поэтому  до сих пор на 2000 скуле.

Именно так и написано, и ускорение заметно даже на глаз.

автор описал только часть задачи. указал в дано проблему но не указал имеющиеся ресуры для её решения (квалификацию,финансы,друзей,...) поэтому два простых совета 1) тк база работает в неоперативном режиме то отключть контроль остатков (если нет восстановления последовательности). 2) отключить блокировку 1с_джорнал (и возможно др таблиц) и проводить парраллельно в несолько программм. Замечу лишь, что перепроведение - преступление, тк теряется историческая достоверность те увеличивается энтрапия.

а как делается п.2 ? Просто интересно.

просто - не интересно.