Так как ты написал, он должен каждый INSERT парсить (миллион итераций * кол-во инсертов в каждом) - прикинь, сколько идёт парсингов!
Ёпрст, конечно при этом рекордсет быстрей!
Потом, где база? если MSJet - то рекордсет ему родной, а INSERT штука чужеродная. Если на SQL-сервере, то такое надо делать хранимой процедурой, или batch-процессингом, или DTS - если MSSQL.

>>если MSJet - то рекордсет ему родной, а INSERT штука чужеродная
Я имел здесь в виду доступ к локальным MDB-таблицам. Потому как когда даёшь ему строку символов "INSERT ляляля ..." он должен это отпарсить, т.е. перевести в цепочку API вызовов, тогда как объекты DAO (коим Recordset является) - всего лишь красивая обертка этих API-вызовов. Изначально, если не ошибаюсь, в персональных СУБД (DBase, Paradox, Access, Clipper, Clarion, etc... etc...) - поддержки SQL не было, а работа с таблицами осуществлялась через вызовы API собственного движка.
Напротив, SQL-сервер работает с клиентом только через строки запросов, и парсить их эффективно - его первейшая задача.

>слова
>>локальным MDB-таблицам
>в данном контексте принципиальны?

Мне казалось, я понятно написал...
Ключевой момент: для доступа к локальным таблицам используются функции API движка (в случае Access движок MSJet, в Delphi это BDE, т.п.), в которых непосредственно происходит работа с источником. Скажем, MoveLast - вот такая функция. Набор из AddNew, Update - вызывают непосредственно функции API движка, ковыряющие непосредственно таблицы. А когда вы даёте движку строку "INSERT ..." (да, вы делаете это посредством вызова некоего метода Execute(), который просто передаёт эту строку в движок), тот должен понять, что переданная строка суть набор команд и данных, и ему в ответ надо произвести последовательный вызов определённых функций, передав им эти данные в параметрах, в результате чего в указанной таблице должна появиться строка (или несколько), содержащая переданные данные. Парсинг - (to parse - разбирать, производить структурный анализ) - это как раз и есть процесс превращения строки символов в цепь вызовов функций API. Если вы знаете SQL достаточно полно, вы можете представлять себе, насколько нетривиальная и сложная сия задача.
А вы её - в цикл!!!

>не ужели, чтобы отпарсить нужно столько времени
>с INSERT примерно в 10 раз медленне работает!
Теперь-то понятно? Передавая строку, содержащую SQL-выражение, вы добавляете дополнительное задание движку, по сравнению с работой через DAO.

Ну а если источник данных - не локальная таблица, а SQL-сервер, то движок ничего сам с этой строкой не делает, он передает её серверу. Поэтому я говорю выше только про локальные таблицы.

Можно сделать и так, чтобы использовать сколько угодно SQL-запросов в каких угодно циклах, не теряя производительности. Если вы в Access, вы конструируете запрос и сохраняете его под к-л именем на вкладке "Запросы" главного окна БД. Неважно при этом, написали ли вы его на SQL или руками слабали, при сохранении произойдет его парсинг, и в базе он сохранится в готовом для использования виде. Вызов такого запроса и передачу параметров делаем через QueryDef.

Почему-то у меня такое ощущение, что Вы всё это знаете...