Имеется у меня вполне рабочая модель данных, которая отлично работает при ручном вводе пользователем. Но попробовал я провести экспорт из Акцеса через эту модель и обнаружил крайне неприятный баг. С увеличением количества данных в базе на сервере, катастрофически падает скорость импорта. Весь ввод данных в БД у меня реализован через хранимки которые я уже только-что не вылизал для оптимизации и не могу понять в чем причина такого зверского замедления работы. Для примера, исходная база содержащая 50 тыс строк, разносится на 300 тыс. разных объектов в базе и все это длится почти сутки! Это же просто пипец какой-то. Сейчас гоняю разные варианты с первой тысячей строк из исходной БД. Пока нет существенного прорыва в скорости.
Пробовал подключать через натив клиента и через адо, принципиальной разницы в скорости импорта не заметил, но вот то что установка свойства CursorLocation в ServerLocation дало не прирост скорости, а очень существенное замедление - стало неожиданным.
В общем жду хоть каких-то идей, куда копать еще.
Система Win10 на i7 c 8 Гб памяти. MS SQL 2017. При всех тестах загрузка памяти не превышает 55%

Кроик Семён,
Возможно вы и правы. Действительно, попробую делать порционные, скажем по 10 пачек объектов в одну транзакцию. Сейчас я вообще без явных указаний транзакций пытаюсь лить в базу.

О да! Как же я раньше то не догадался о транзакциях. После разбиения на порции все стало существенно лучше заливаться.

План - это сильно сказано. Все хранимки выполнены по одному шаблону простой селект и такой-же простой инсерт, но в процессе импорта на каждый пакет данных приходится в среднем по 2 десятка вызовов хранимок.

Нашел я в чем у меня была основная проблема замедления. Все оказалось до смешного просто - для обновления датасета в приложении используется Requery, но при импорте я отключаю с помощью флага эту инструкцию. Оказалось, что в одном месте я этот флаг не поставил и в итоге, чем больше данных в БД, тем длительнее Requery, но тем не менее подсказка с транзакциями была удачна и значит не зря тему завел. Всем спасибо.

А я и сделал, а когда обнаружил, что сумма всех вызовов хранимок за один проход цикла, даже отдаленно не совпадает с итогом по циклу, наконец то и обнаружил слона. :)