Создание большого числа заказов на продажу. Падение скорости загрузки.

[mazzy]

Скорее всего, у вас установлен Recovery model = Full на SQL-сервере.
Это значит, что все транзакции сохраняются до бэкапа. Из-за массовой вставки у вас безумно растет transaction log на SQL-сервере. А поскольку у вас идет постоянное замедление то рискну предположить, что шаг роста слишком маленький и львиную долю времени SQL-сервер тратит не на выполнение транзакций, а на увеличение файла.

Если это так, то увеличивайте инкремент для trnasaction log или делайте чаще бэкапы. А еще лучше курите админские доки.

Кстати, эффект когда на прогресс-бар показывает постепенное замедление связан с тем, что прогресс-бар использует среднюю оценку - он усредняет быстровыполненные операции с медленно выполняющимися последними. Поскольку медленно выполняющихся становится все больше, то и среднее потихоньку увеличивается, при этом потихоньку увеличивается и оценка оставшегося времени. А на самом деле, скорее всего, с какого-то времени все операции у вас выполняются одинаково медленно


Если вы покурили админские доки, но это не помогло,
то есть другой момент:

Цитата:

Сообщение от bobski

NumberSeq = NumberSeq::newGetNumFromCode(SalesParameters::numRefSalesId).numberSequence);
salesTable.SalesId = NumberSeq.num(); 
...
ttscommit; 
}

Проверьте, не используете ли вы непрерывную номерную серию для заказов.
Если используете непрерывную, то исправьте код - у вас не хватает вызова метода NumberSeq.used().
Вы не фиксируете факт использования номера, в итоге список незафиксированных номеров у вас растет со старшной силой.

[bobski]

Все верно, Сергей. Модель восстановления - полная. Серия непрерывная. А вот с прогресс баром это интересно.
Я его обновляю после каждой затяжки, каждой из строк.

progress.setText(strfmt("Обработано записей: %1", CurrentOperationProgress));

Ясное дело, что обновляется прогресс бар через определенный промежуток времени. Допустим, что каждую секунду. Стало быть такт = 1сек. Так вот в самом начале процесса загрузки число обработываемых строк за такт около 300. Постепенно, при обновлении прогресс бара число обработанных за такт строк снижается. И к пятой-шестой минуте снижается до позорных 50 за такт. Странно.

Прошу прощения за следущий вопрос: где увеличить инкремент для trnasaction log?

[mazzy]

Цитата:

Сообщение от belugin

В аксапте сравнение регистронезависимое. Для регистрозависимого надо использовать strCmp

О! Спасибо, добрый фей. Стало быть я лишний код пишу...

Цитата:

Сообщение от bobski

Все верно, Сергей. Модель восстановления - полная. Серия непрерывная.

проверяйте.

Цитата:

Сообщение от bobski

Ясное дело, что обновляется прогресс бар через определенный промежуток времени. Допустим, что каждую секунду. Стало быть такт = 1сек. Так вот в самом начале процесса загрузки число обработываемых строк за такт около 300. Постепенно, при обновлении прогресс бара число обработанных за такт строк снижается. И к пятой-шестой минуте снижается до позорных 50 за такт. Странно.

А дальше снижается или так и остается 50 за такт?

Цитата:

Сообщение от bobski

Прошу прощения за следущий вопрос: где увеличить инкремент для trnasaction log?

В SQL Server Management Studio