вот такой вопрос. а как добиться прироста скорости проведения.
ведь при восстановлении последовательности обычным методом метод РассчитатьрегистрыНа() не будет задействован так как при штатном режиме Итоги всегда Актуальны?
соответственно при восстановлении последовательности штатным методом
будет быстрее чем 1с++ или я ошибаюсь?

?

?

?

так все же?

Пиши АЛьФу

1C++ все равно быстрее, особенно если прямыми запросами не только расчитывать регистры, но и формировать готовые таблицы по списанию регистров (например, распределение по партиям). Опять же использование ReconnectNative() заметно убыстряет массовое проведение

Изай РеконнектНатив, вполне достаточно. В принципе, ВГП ничем не отличается от проведения на ТА. Единственный глюк - глюк сиквела с замедлением - решает РеконнектНатив() из 1С++, или (говорят, более успешно) софтпойнтовская компонента. У меня ВГП с РеконнектНатив работает с июля 2005 года.

(7) кинь пример, если не сложно плз

(8) Пример чего?

пример восстановления последовательности с использованием (7)

А чего там военного? Перебираешь документы по последовательности, и проводищь.
через ццццать документов -
       Текст.ДобавитьСтроку(" "+ТекущееВремя()+" - переподключение");
       база = СоздатьОбъект("ODBCDatabase");
       база.ReconnectNative();
       база = 0;
И дальше....

(11) понял, а я то думал ...

(12) Дык и я о том же. "Ничо ваенного, ничо зилёнаво"©
Если без реконнекта каждый час количество перепорведенных доков падает в среднем на 15% - то тут падения нет. А "съэкономленное - значит заработанное"
Хотя по-идее, можно еше выборку организовать через прямой запрос. Это идея, процентов 50 накладняка съэкономит.
Спасибо аффтару ветки за индуцированную идею! :-)

(0) Групповое проведение документов быстрее обычного восстановления примерно на порядок. Сгодня ночью проверил...

(14) Что есть "групповое проведение" и что есть "обычное восстановление"?

(15) Групповое проведение - это когда при формировании реестра в журнале документов нажимается кнопка настройка выскакивает обработка документов. В современных конфах нужно кроме периода выбрать вид обработки - провести, обрабатывать документы - проведенные.
Обычное восстановление - это когда отчёт говорит, что нарушена ГП и предлагает восстановить.
Правда, в (14) я немного подменил понятия. Конфа у меня древняя, но смысл групповой обработки я думаю сохранился. А под обычным восстановлением в том же случае у меня была обработка, которая перепроводила все проведенные документы за указанный период. Есть предположение, что результаты должны коррелировать. Проверять нет желания.

(11) насколько мне помнится, при реконнекте выборка документов сбрасывается и приходится выбирать из заново? или я чего не так понял...

(16) что-то не верится...

(18) На проведение обработкой при использовании транзакции у меня ушло больше 12-ти часов, групповое проведение заняло около часа...

(19) какой такой транзакции? Если ты восстанавливаешь последовательность штатно (тока монопольно надо), то сдвигается ТА назад и итоги при проведении всегда актуальны. Насколько я знаю, это самый быстрый способ ШТАТНОГО проведения документов (без использования всяких ВК)...

(20) А штатно - это как?

(21) штатно - это используя встроенный язык 1С, без привлечения ВК (типа прямых запросов)...

(22) попробуй сравнить с групповым проведением, описанным в (16). Результат может неожиданно порадовать.

(16) просто при групповом проведении не переносится ТА и итоги не пересчитываются а расчет происходит в самом документе методом РассчитатьРегистрыНа()
в моем же случае при переделке на 1с++
именно групповое проведение выигрывает в скорости (по "тупому алгоритму 1С" то есть каждая строка отбрабатывается отдельно, но вместо 1с я использовал 1с++)
тут прирост скорости достигался от 2 до 5 раз.

(16)Ну, блин, а чего ж ты хотел - то, что ты называешь "групповым поведением" - делается со сдвигом ТА, а то, что делается по предложению проги во время выполнения отчета - без сдвига. Вот и все. И вполне естественно, что со сдвигом ТА все будет гораздо быстрее. Так что ничего нового ты не открыл.
(17)да

вот в связи с этим и возник вопрос. а как при штатном проведении??? и проведении 1с++
как лучше организовать алгоритм 1с++ что бы все же добиться прироста скорости?
потому как по замерам
ПолучитьСводныйОстаток работает немного быстрее
чем РегистрОстатки.ОстаткиТМЦ () например
а при штатном восстановлении итоги всегда актуальны.
если только написать обработку по перепроведению которая сдвинет ТА на ГП потом в выборке перепроведет все доки и сдвинет ТА туда где было.
то есть без переноса ТА после проведения каждого дока. может так быстрее будет?

(24) Наоборот, при "групповом проведении" ТА переносится на самый ранний документ и ползет вперед с проведением каждого последующего. ПОэтому каждый документ проводится на ТА (что быстрее, т.к. НЕ используется РассчитатьРегистрыНа ), и соответственно, более поздние итоги не пересчитываются.

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

(26) найди в КЗ статью Ангела-Хоронителя "По ночам должны работать роботы". Там пример обработки восстановления ГП со сдвигом ТА. Если сдвинешь ТА, то прямой запрос к вирт. таблице остатков должен работать еще быстрее...

(28) При запуске "через отчет" он и НЕ сдвигает ТА. Т.к. предназначена эта фигня для работы в разделенном режиме.
А "операция"-"проведение документов"-"последовательности" требует монопольного режима - именно из-за сдвига ТА.

(29) Там уже можно и не виртуальной таблицей пользоваться, а реальной. Ты ж на ТА стоишь :-)

(31) тоже верно...

В принципе ТА тоже можно переносить прямыми запросами, чего я не делал в нижерасположенной обработке
Вот тут пример восстановления последовательности с реконнектом (только надо иметь приличный глобальный модуль, без курсорчиков :))
Замер производительности можно убрать чтобы было быстрее
http://infostart.ru/profile/2140/projects/1151/

(31) тут я уже сам понял
если итогиактуальны то дату расчета просто не передаем....
вот и добрались до истыны относительо (0)