Смешивание DAO и ADO в том же приложении действительно не представляет никаких проблем или осложнений. Я думаю, что ваш вопрос действительно имеет гораздо больше общего с тем, когда и почему вы будете использовать тот или иной.
Моя собственная стандартная политика в Access Development заключалась в использовании ADO только тогда, когда DAO не будет работать для чего-то, что я хочу сделать. Например, с ADO вы можете получить доступ к хранилищам данных, отличным от Access, например Visual Foxpro, Oracle, MySQL и т. Д. Но ADO не всегда требуется для достижения этого, поскольку вы часто можете использовать ODBC, а это значит, что вы будете использовать DAO вместе с связанными таблицами ODBC.
Недавно у меня несколько переключенных передач, где я предпочитаю использовать ADO исключительно, но я понимаю, что это не обычная практика среди многих опытных разработчиков Access. Я использую SQL Server 2008/2012 Express и формы, привязанные к наборам записей ADO, и я вообще избегаю любых связанных с ODBC таблиц. Моя основная причина заключается в том, что ADO дает мне несколько дополнительных возможностей и больше контроля, хотя это и связано с его затратами. Я использую много отключенных наборов записей, а затем я «вручную» (VBA) записываю изменения обратно в базу данных, только если пользователь нажимает кнопку сохранения. Это дает пользователю возможность сделать кучу изменений в форме и ее подформах, но все равно отменяет, если он выберет. При отключенных наборах записей ADO вам решать, как получить изменения данных на сервере, хотя не связанные с отключением наборы записей автоматически отправляют свои изменения. Насколько я могу судить, единственный тип набора записей ADO, который автоматически получает все добавления, изменения и удаления с сервера (adOpenDynamic) cannot be bound to a form, но это действительно не вызывает большого беспокойства, если вы просто хотите использовать связанные формы ADO для добавление/редактирование/удаление записей.
Я читал множество мест, в которых ADO не имеет каких-либо преимуществ по сравнению с DAO, а в некоторых случаях может быть медленнее. Я не могу сказать так или иначе, но я не думаю, что это большая проблема. Преимущество ADO в том, что вы действительно можете заставить свое приложение работать через медленные и/или нестабильные сетевые подключения (например, WAN/Интернет), что действительно невозможно в DAO/ODBC. С чистым решением ADO вы отвечаете за обработку объекта соединения и всех выборок данных. Вы можете установить тайм-ауты соединения и команд, и если тайм-ауты произойдут, соединение не удастся и т. Д., Вам решать, как с ним справиться. Например, вы можете сделать X количество попыток повторного соединения. В DAO/ODBC это невозможно. Насколько я знаю, объект соединения даже не подвергается воздействию ODBC, за исключением того факта, что вы можете настроить строку соединения ODBC.
В ADO требуется гораздо больше кода, чтобы делать все в ADO, особенно если вы хотите использовать отключенные наборы записей. Записи должны быть получены (или сфабрикованы) с использованием кода. Если вы используете отключенные наборы записей, данные должны быть возвращены на сервер с использованием кода.Независимо от того, используете ли вы отключенные или подключенные наборы записей, отношения с мастером/дочерним по формам должны управляться вручную с помощью кода (вы не можете использовать свойства «Мастер/дочерняя ссылка»).
Одним из потенциальных недостатков с ADO является невозможность привязки отчета к набору записей ADO, если вы не используете проект Data Access Project, который на данный момент не рекомендуется, поскольку MS отказывается от поддержки АДФ-х. Если вы хотите использовать что-то другое, кроме DAO для данных в отчете, вам придется использовать Pass Through Queries, и если ваше хранилище данных - это MS Access, это не имеет смысла делать это.
Я думаю, что любое обсуждение связанных и несвязанных форм совершенно не связано с любым обсуждением DAO и ADO. Формы могут быть привязаны к наборам записей ADO с очень небольшим количеством компромиссов. Несвязанная форма могла получить его данные из набора записей DAO или набора записей ADO, и не было бы никакой разницы, поэтому несвязанные формы и ADO больше не связаны или не связаны друг с другом, чем DAO и несвязанные формы. Я действительно использую только несвязанные формы для создания своих собственных ящиков сообщений и определенных типов полей ввода или записей. Обычно это случай, когда мне нужны данные, отображаемые на кнопках для приложения с сенсорным экраном, а затем я иду без ограничений. Если бы я мог получать подобное поведение из текстовых полей (и, возможно, я мог бы, если бы я достаточно старался), было бы мало случаев, когда необходима несвязанная форма.
Мне кажется, что была распространена идея, что несвязанные формы - это способ, которым настоящие профессионалы разрабатывают приложения Access. Или что несвязанные формы - это единственный способ получить производительность. Или что несвязанные формы следует использовать, если вы не используете MS Access в качестве хранилища данных. Но ни одна из этих идей не выдерживает никаких пристальных взглядов. Формы привязки к наборам записей ADO намного проще, чем полностью исключить. И даже без возможности использования Datasheet Views или Continuous Forms невозможно. Если вы действительно хотите отключиться в виде сетки, вам придется использовать элемент управления сетью ActiveX, такой как iGrid из 10tec, или элемент управления представлением MS List, который обычно имеет больше накладных расходов, поскольку есть время, необходимое для получения записей и дополнительное время, необходимое для заполнения элементов управления сеткой данными. Несвязанная форма не имеет прироста производительности, о которой я могу думать о привязке формы к набору записей ADO. И нет действительно никакого хранилища данных, который не может использовать ADO Recordset, даже если вам нужно использовать скомпилированный набор записей ADO.
Это огромное упрощение, но ваш основной прирост производительности в MS Access достигается за счет максимизации производительности вашего хранилища данных (что обычно означает переход на SQL Server) и тщательное управление количеством данных, которые вы загружаете и представляете пользователю. Самый простой способ сделать это с ADO, но вы также можете сделать это с DAO/ODBC. ODBC фактически имеет одно преимущество над ADO, называемое ленивой загрузкой. Вы можете привязать форму таблицы данных или непрерывную подформацию к очень большому набору записей таблицы/DAO и загрузка каждой записи будет происходить при прокрутке. Его особенность, которую я не очень люблю, и у меня были пользователи, жалующиеся на это, так как вы не видите записи до тех пор, пока не отпустите полосу прокрутки, но я должен был бы утверждать, что это один из самых эффективные способы обработки больших объемов данных (> 50 000 записей).
Существует довольно обширный article on the UtterAccess Wiki that details the pros and cons of DAO versus ADO (обратите внимание, что статья удалена, и единственный способ ее просмотра - посмотреть историю того, что было в одно время. Просто убедитесь, что вы прокручиваете вниз ниже diff/сравнения). И еще есть great article on unbound forms at AccessExperts.com written by Juan Soto.
ADO и DAO оба могут успешно использоваться в одном приложении Access db. Я делаю это часто без проблем, поэтому я действительно не понимаю вашу озабоченность. Также я не понимаю, как связанный и несвязанный вписывается в этот вопрос. Если вы столкнулись с проблемой, которая, как представляется, вызвана конфликтом между ними, задайте вопрос конкретно об этой проблеме. – HansUp