Показать сообщение отдельно
Старый 02.11.2004, 09:49   #9  
db is offline
db
Роман Долгополов (RDOL)
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
 
393 / 692 (24) +++++++
Регистрация: 01.04.2004
Адрес: Москва
Цитата:
Изначально опубликовано AlexNSK
ну а может это нормальная скорость? у кого были более высокие результаты на подобной конфигурации?
Скорость действительно нормальная. И самое главное - посчитайте нужно ли Вам быстрее. Посчитайте, сколько времени нужно на разноску всех этих заказов + сколько времени нужно на операции после разноски (сводное планирование и пр. тяжеловесные операции, зависящие от актуальных остатков). Если времени ночью достаточно, то лучше принять ситуацию как есть. Существенного уменьшения времени разноски на стандартном функционале только с помощью настроек вы не получите. Если же времени в сутках не хватает, а параллельно ваши операции работать отказываются или начинают жутко тормозить, то придется кодировать

У меня была ситуация с необходимостью создавать и разносить ~300 000 строк заказов за максимум 3 часа. Пришлось написать собственный разносчик z-отчетов, который выполнял создание и разноску заказа со скоростью 2000 строк в минуту. Вместе с разноской формировались накладная и фактура, проводки в ГК с корреспонденцией счетов, считались налоги и т.д. - с точки зрения результатов оба алгоритма идентичны. Никакие извращения типа вызовов хранимых процедур не использовались - только чистый X++.

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

Код выложить или подарить не могу - он принадлежит не мне, а заказчику.