#excel #vba #ms-access
#excel #vba #ms-access
Вопрос:
Я использую Excel vba для извлечения данных из базы данных MS Access — для этого используются Excel 2013 и Access 2013 32bit. Исторически код использовал:
Provider=Microsoft.Jet.OLEDB.4.0;
Однако некоторые компьютеры обновлены до 64-разрядной версии Excel 2016, а поставщик Jet недоступен для 64-разрядной версии. Я изменил код на:
Provider=Microsoft.ACE.OLEDB.12.0;
который работает как для 64-разрядных, так и для 32-разрядных систем. Однако я заметил значительное снижение скорости загрузки / сохранения данных только из-за изменения этой строки. Кто-нибудь знает, почему это может быть и как я могу это улучшить?
Комментарии:
1. Это полностью зависит от того, что делает код. Я не могу представить или испытал такое падение скорости. Рассмотрите возможность редактирования вашего вопроса со спецификой, поскольку он слишком широкий.
2. Я предполагаю, что компьютеры, обновленные до Excel 2016, также обновлены до 64-разрядной версии Access 2016?
3. @zac да, это также
4. @Parfait код на самом деле просто вставляет строку в базу данных access, а затем вызывает обратный запрос в базу данных access
5. запрос может быть любым. Пожалуйста, опубликуйте пример!
Ответ №1:
Вы правы в выборе поставщика ACE для 64 бит.
И большим преимуществом JET было то, что он был (и остается) установлен во всех копиях Windows по умолчанию. Таким образом, нет необходимости устанавливать Access или среду выполнения, или предыдущий пакет office connectivity.
Что касается производительности? Было несколько замечаний по поводу производительности в отношении ACE x64.
Однако один трюк или предложение заключается в том, чтобы убедиться, что соединение остается открытым. Другими словами, вы уверены, что обработка строк идет медленно, или это общее время?
(возможно, установите флажок test msg или test в свой код.
Например:
Dim T as single
T = timer()
‘ your code here
Debug.print timer() – t
Таким образом, в приведенном выше примере будет указано время до окна отладки (в то время как в среде разработки VBA нажмите ctrl-g, чтобы отобразить окно немедленной отладки.
Причина, по которой я предлагаю принудительно открыть idea, часто заключается в том, что для открытия ACE требуется ОЧЕНЬ много времени. Но после открытия считывание данных имеет хорошую производительность (такую же, как и раньше).
Итак, я предлагаю проверить и попробовать это исправление.
Итак, откройте таблицу (любую таблицу) и ДЕРЖИТЕ ее открытой. Теперь запустите существующий код (который вполне может открывать закрывать другие таблицы). Проблема в том, что когда ACE пытается открыть таблицу, он пытается установить блокировки на файл mdb / accdb, и именно этот процесс занимает ОЧЕНЬ, ОЧЕНЬ много времени.
Однако, если вы принудительно открываете (сохраняете) одну таблицу, то этот ОЧЕНЬ медленный процесс, когда ACE пытается заблокировать файл для чтения / записи, не происходит каждый раз, когда вы выполняете запрос или создаете дополнительные наборы записей в коде.
Итак, если скорость чтения строк высока, но время ЗАПУСКА открытия очень низкое, то перед запуском протестируйте свои процедуры принудительно откройте таблицу в некотором reocrdset (оставьте ее активной и в области видимости), а затем попробуйте свой код.
Я нахожу, что в 9 случаях из 10 это приводит к устранению этой низкой скорости, и часто я видел, что результаты не что иное, как впечатляющие (он будет работать быстрее, чем раньше !!!)