Экспериментирую тут с заливкой большого объема данных в базу Access.
Данные заливаются в одну таблицу, которая не имеет ни ключей ни индексов.
Берутся данные из заполненного массива.
Пробовал следующие способы в порядке возрастания времени работы:

1) - 192 секунды
rst.Open strsql, cnnData, adOpenStatic, adLockBatchOptimistic
.AddNew
rst.UpdateBatch

2) - 228 секунд
rst.Open strsql, cnnData, adOpenKeyset, adLockOptimistic
.AddNew
.Update

3) - 248 секунд
cnnData.Execute strsql, , adCmdText + adExecuteNoRecords

4) - 254 секунды
cnnData.Execute strsql

Последние на равных почти, а кругом обещали что 3 быстрее 4. Ну да не в этом вопрос, как бы все это ускорить? И почему так долго, в то время когда импорт из текстового файла те же самые 30000 строк в ту же таблицу занимает пару-тройку секунд?

XED30000? там пять нулей, да? :)
попробуй просто использовать другую СУБД. Скажем, SQL-Server, может, Oracle... просто не стоит лишний раз при серьезной работе опираться на Microsoft...
Да 30 000. Заливаю это дело через VB6 на компе с 512 мегами памяти и 800 пнем. Нужна именно локальная база в файловом формате.

WorobjoffМожно почти удвоить скорость заблокировав таблицу на время апдейта:

Не, жалкие 20 секунд выигрыша получились. Да и UpdateBatch тут не катит, юзер в это время наблюдает как прога повесилась и за одно повесила систему слегка и он в панике начинает жать на все подряд или даже на ресет :)
DAO тут впереди планеты всей, в разы! Проверил. Но не хочется с ним связываться, слишком много воплей по форумам что не на всякий комп встанет программа написанная с применением DAO. Или у народа руки кривые.

XEDПослушай, браток, просто попробуй использовать более скоростные СУБД - Access для этой цели явно не подходит. И не в VB надо писать программу, работающую с этой БД. Это просто объективная реальность. Ты говоришь в первом сообщении, что если при использовании текстового файла время исчисляется единицами секунд... естественно! текстовый документ имеет последовательную структуру! А реляционные БД построены на ссылках и переходах - не зависимо от того имеются ли в ней ключи, индексы и прочая лабуда.
Советую просто использовать другие инструменты - другую СУБД (оракл, например, либо SQLServer), ну а если игра вообще стоит свеч, то имеет смысл разработать специализированную систему хранения данных (раз уж ты говоришь об одной таблице) и писать специально под эту систему скоростные процедуры доступа, обернуть их в библиотеку и пользовать хоть бы даже в том же VB
Благодарю за совет, но ты ничего не понял и делать нужно на Access. 30000 это крайний случай с которым может столкнуться программа, т.е. проверка ее на большой нагрузке. Насчет тектового файла ты опять же ничего не понял, советую перечитать.

nibblesребятки, я все понимаю - выходные, праздники... но такого я от вас не ожидал... :)) ну не подзревать же вас всех в том, что вы не знаете, с какой стороны подойти в таких случаях к Аксессу, а? ;))

1. сколько занимают 30 тыс. иттераций без добавления записи в таблицу (если заменить ".AddNew" на "debug.print rst(0).value")? Вы уверены, что это тормоза получателя данных, а не источника?

2. где физически находится получатель данных и кто к нему в этот момент подключен кроме Вас?

3. какие индексы, ключи, ограничения и связи наложены на таблицу-получатель? или вы считаете,что их переопределение не занимает у СУБД времени?

4. (собственно предложение), перегон таких объемов для клиент-серверных приложений иттерационными циклами - нонсенс и вопрос о времени в этом случае вообще не должен подниматься. Как правило - это разовые задачи для начального наполнения БД - пресловутая "конвертация" данных, которую можно и подождать пару минут. Если же очень надо, и быстро, то подключайте эти 30 тыс. строк в качестве таблицы (в каком-нить файловом виде они ведь у Вас хранятся?) и используйте INSERT INTO ... SELECT FROM... Это решит Вашу "проблему" за 1...5 сек.

5. если руки не из того места растут, то микрософт (вообще) и аксесс (в частности) тут не при чем. Пока из доступных файл-серверных БД он натурально лучший - не стоит его хаить и рекомендовать переход с него на что-то другое... уверен, что на этом "чем-то другом" ситуация будет такой же...

6. автор, будьте последовательны: если Вы используете конструкцию with...end with, то используйте ее для всех методов объекта - это сэкономит толику ресурсов.

XED30000? там пять нулей, да? :)
попробуй просто использовать другую СУБД. Скажем, SQL-Server, может, Oracle... просто не стоит лишний раз при серьезной работе опираться на Microsoft...
SQL Server тоже сделан на микрософте. Кроме того, иттерационный способ добавления записей займет у него примерно столько же времени... У Оракла - аналогично.
Щас все объясню.
Мы (я), не совсем уж дураки/дубы/кретины, нужное подчеркнуть :) Никаких debug.print, doevents в эксперементах не участвовало. Доказательством того что это тормоза библиотек в том что при отключении действий с рекордсетами, цикл по данным в массиве пролетает за пару секунд.
1) Собственно вот, тормозит не получатель, а библиотека доступа, если я не очень криво выразился.

2) Физически получатель лежит в той же апке что и программа и кроме меня к ней не цепляется никто.

3) про ключи индексы и прочее я уже писал выше, для чистоты эксперимента их нет.

4) Как раз это решение и найдено, но выглядит оно несколько некрасиво. Так же найдено второе решение, а именно DAO без всяких файлов уделал ADO в разы.

5) Я только за Access да и VB не так уж плох как его хают.

6) Предполагаю что экономятся сущие копейки, но за замечание спасибо.