Connection.Execute быстрее и ... надёжнее CurrentDb.Execute?..

(А2003, ХР3, W7 64)
От нечего делать решил их сравнить. (И думал, что CurrentDb проще и быстрее.) Пол дня потратил - у меня результат получился однозначно в пользу первого (если не считать, что больше на четыре строчки кода...)
Есть серия последоват продолжительных запросов (импорт дбф и тхт во внешнюю бд: добавление и обновление). Особенно заметно на апдейтах: примерно 47-50 против 60, а когда и 65(!) у CurrentDb (инсерт - примерно 27 на 34). Да и это бы ладно...
Application вдруг напрочь отказался видеть одну из однотипных таблиц. Не хочет и всё: "выходная таблица с именем ... не найдена ядром". И на инсерте, и не апдейте. А она есть, открывается, место занимает. И при этом ADO прекрасно её "видит" и обрабатывает... А почему, интересно? Я чего-то не знаю?

Не совсем понятны выводы ТС.

Connection - это ADO (CurrentProject.Connection.Execute)
CurrentDB - это DAO (CurrentDB.Execute)

Так что же быстрее DAO или ADO? Здесь вроде бы несколько раз возникал спор об этом.

Вот у меня несколько раз случались такие вещи. (А2003 SP2, XP SP3). Замечено только с запросами на добавление или изменение.
Создаю хранимый запрос на добавление или изменение.
Запускаю через ADO (CurrentProject.Connection.Execute) - вылетает по ошибке (типа "не могу найти таблицу или поле")
Запускаю его же через DAO (CurrentDB.Execute) - всё работает.

Один раз такое случилось в процессе отладки. Запрос нормально выполнялся в ADO. Но в один прекрасный миг начал вылетать по вышеназванной ошибке. Сколько не бился, не смог понять, почему? Пришлось в этом случае перейти на DAO.

ADO хорошо тем, что его можно применять в проектах Access , а DAO - нет.

Joss
Не совсем понятны выводы ТС...

Собственно говоря, никаких выводов и нет. Приведённые цифры - замеры времени выполнения процедуры в секундах

Joss
...ADO хорошо тем, что его можно применять в проектах Access , а DAO - нет.

Ценная информация, спасибо. Вот и надо, значит, при возможности сразу пользовать ADO. Чтобы впоследствии не "переименовывать" полбазы. Тем более ADO же вроде более "продвинутая", современная технология?..

EvAnd
Joss ...ADO хорошо тем, что его можно применять в проектах Access , а DAO - нет. Ценная информация, спасибо. Вот и надо, значит, при возможности сразу пользовать ADO. Чтобы впоследствии не "переименовывать" полбазы. Тем более ADO же вроде более "продвинутая", современная технология?..

Ага. Сразу ставьте MS SQL сервер, создавайте ADP проект и забудьте джетовский SQL как кошмарный сон...

Программист-Любитель
Сразу ставьте MS SQL сервер, создавайте ADP проект и забудьте джетовский SQL как кошмарный сон...

Программист-Любитель, договорились. Расчитываю теперь на ваш хэлп. :-)
(Долго, кстати, в первый раз морочились с миграцией?)

Программист-Любитель
забудьте джетовский SQL как кошмарный сон...

Писать простыни case when then вместо iif ?

alvk
Писать простыни case when then вместо iif ?

Сравните читабельность кейза с трех-четырехэтажным иифом.

По сути предмета: к сожалению, микрософт собственными руками душит сей замечательный подход. Развитие адп закончилось на 2003 офисе. Я сам сижу на связке аксесс 2003 + скл сервер 2005. Это уже сильно устаревшее сочетание по сравнению с а2007, 2010 и скл сервер 2008. По новым связкам дельных советов могу дать ровно столько, насколько в них останутся работоспособны приемы и техника старого сочетания.

Мигрировал очень недолго - приложение было небольшим. Сделал это один раз, как только появилась хорошо работающая связка а2000 + скл сервер 2000. Но после этого смотреть на джетовский мдб без рвотного рефлекса больше не мог.

Вроде бы А2007 поддерживает ADP созданные в А2003. И MS SQL Express 2008 R2 ещё та штучка. Поддерживает новые форматы (например геокоординаты), а как в Access с ними разбираться?

Joss,

2010 тоже нормально работает с адп.
И с созданными в ранних версиях, и со своими.

adv
и со своими.

тут я немного погорячился :)

Он создаёт адп в формате 2003, о чём и предупреждает :)