Не особо о чем тут писать.
В Access есть несколько «контейнерных» объектов.Мы можем хранить изображения, PDF-документы или что-то еще в этих контейнерах.
И мы могли бы даже хранить, скажем, диаграмму Отношений в этих контейнерах.(Ой, подождите - они сделали это !!!).
Контейнеры - это просто некоторые контейнеры в приложении Access.
Таким образом, они могут произвольно представлять собой что угодно, что дизайнеры приложений Access хотели сохранить в контейнерах.
Я имею в виду, на самом деле, это не сильно отличается от стола.В этой таблице могут быть счета-фактуры или, скажем, некоторые клиенты
ПОЭТОМУ сделать вывод, что в DAO имеется объект «клиенты» или объект «счет-фактура», как часть объектной модели DAO, здесь будет мало смысла.
Контейнеры «объекты» - это всего лишь контейнер вещей.Они имеют мало отношения к объектной модели DAO.
«Контейнеры» - это список объектов, предоставляемых системой Access, а не DAO.
Не существует метода «контейнеров» или «контейнеров».”Свойство объектной модели DAO.
Теперь, чтобы быть справедливым,« родным »механизмом базы данных, используемым в Access, является JET (теперь называется ACE).И, честно говоря, поскольку ядро базы данных доступа ОЧЕНЬ близко связано с объектной моделью DAO, то, безусловно, справедливо утверждать, что Access (инструмент разработчика) связан гораздо ближе к DAO, чем к ADO.
Хотя вы наиболее свободно можете использовать DAO или ADO для получения данных из механизма JET / ACE, DAO, безусловно, является предпочтительным выбором здесь.
«Основная» причина этого предпочтения заключается в том, что DAOОЧЕНЬ тесно связаны с ядром базы данных JET / ACE.Первоначально Access был основан на коде библиотеки JET + dao, поэтому его корни более тесны в объектной модели DAO.
Однако, если вы собираетесь получать данные с SQL-сервера, то в течение долгого времени большинство разработчиков предпочиталиобъектная модель ADO.Есть несколько преимуществ использования ADO, если, скажем, использовать SQL-сервер, или, скажем, MySQL или Oracle в качестве внутренней базы данных с MS-доступом в качестве внешнего интерфейса.
«Основным» преимуществом использования ADO является то, что SQL, используемый для ADO, «ближе» к синтаксису SQL, который использует «отраслевой» стандарт (ansi-92).В результате ваш SQL, который вы пишете с помощью ADO, будет работать (в общем) без изменений, если вы используете SQL-сервер или скажете Oracle в качестве серверной части.(И вы, вероятно, можете переключаться между двумя базами данных без необходимости изменения используемого синтаксиса sql).
В DAO вы используете Access (jet) SQL-синтаксис или, точнее, синтаксис JET / ACE.Когда вы используете ADO, но все еще используете движок JET / ACE, вы можете использовать синтаксис sql ansi-92.В результате ваш синтаксис для sql НАМНОГО больше будет соответствовать синтаксису, используемому на SQL-сервере, или, скажем, oracle.
Для приложений access + JET / ACE рекомендуемым стандартным выбором является использование DAO.(18 лет назад Microsoft изменила объектную модель «по умолчанию» на ADO в Access 2000. Разработчики устроили «восстание»), и в Access 2003 они вернули DAO по умолчанию. (Вы можете до сих пор выбирать все равнообъектная модель или, что еще хуже, «смешать» две - не ходите туда !!!). Таким образом, Microsoft не заставляла изменение, но настройкой «по умолчанию» было ADO - но мы просто всегда меняли ссылку на DAO и сохранялина написание кода, как мы всегда это делали.
Так что в течение многих лет Microsoft подталкивала всех к использованию ADO - включая очень популярную систему MS-доступа.
Однако большинство из насразработчики проигнорировали этот совет от Microsoft, и cПродолжайте использовать DAO при создании приложений с собственным доступом.И, как уже отмечалось, довольно долгое время DAO является объектной моделью по умолчанию.Поскольку DAO несколько устарела, команда Access взяла библиотеку объектов и кода DAO, и теперь они владеют этой библиотекой.(Раньше это была просто стандартная библиотека Microsoft, которую могли использовать все разработчики).Так что для V6, vb.net и т. Д. Они обычно использовали ADO.
Таким образом, теперь вы можете «прочитать», что DAO устарела, но Access использует обновленную и более новую версию, которая включена в ядро базы данных ACE.,(Таким образом, в то время как DAO как автономная библиотека объектов является устаревшей, код DAO обновляется, и новые функции продолжают действовать в Access как объект обработчика данных ACE.
Когда вы устанавливаете ссылку на обработчик данных ACE, тогда все вашиКод DAO должен работать просто отлично. Что это значит (начиная с Access 2007), вам НЕ нужно устанавливать внешнюю ссылку на объектную модель DAO - теперь она является частью ядра базы данных JET / ACE (до доступа 2007 выЯ должен был установить ссылку на DAO. И если вы собираетесь использовать ADO, вы ВСЕГДА должны были установить эту ссылку, и вы все еще делаете это по сей день)
Это изменение было сделано, поскольку на самом деле только сообщество Access иразработчики использовали DAO - большинство других платформ использовали ADO (по многим причинам, но одной из основных причин было то, что ADO НЕ был связан и не имел корней в ядре базы данных MS-access, как это делает DAO, и до сих пор существует по сей день.
Помните, что в течение 5-10 лет у Microsoft не было SQL-сервера, поэтому Access + DAO был их «большойal ». Когда они наконец начали продавать SQL-сервер, то, конечно, все изменилось в связи с продвижением Microsoft DAO.DAO была «первичной» технологией механизма доступа к MS.
Если вы в будущем переместите данные из Access на сервер SQL и продолжите использовать MS-доступ в качестве внешнего интерфейса графического интерфейса, доступСообщество STILL предлагает вам придерживаться любой объектной модели, которую вы использовали для разработки своего приложения.Таким образом, доступ к приложениям, разработанным с помощью DAO, но с использованием сервера SQL в качестве внутренней базы данных, работает нормально и должен оставаться таковым.
И если вы разрабатывали с ADO, вы хотите продолжить, если вы начнете использовать сервер SQLс доступом.Обратите внимание, что я имею в виду код VBA, который вы пишете - специфические наборы записей ADO.
Вы по-прежнему всегда используете «те же» внутренние контейнеры, которые существуют в Access - эти контейнеры НЕ меняются, если вы используете ADO или DAO при написании кода для изменения данных в клиенте доступа.
ADO, безусловно, имеет некоторые преимущества, если вы собираетесь использовать, скажем, SQL-сервер в качестве бэкенда от «первого дня» с Access в качестве внешнего интерфейса, но даже в тех случаях, если ваше приложение доступа было написано с использованием DAO, тоЯ бы продолжал использовать DAO - даже с сервером SQL.
Однако для разработчиков .net, разработчиков Visual Basic, они, вероятно, оттачивали свои навыки, используя объектную модель ADO и когда они используют MS-доступ в качестве разработки.инструмент, тогда они могут продолжать использовать свое «долгое время», знакомое с объектной моделью данных ADO при написании кода в MS-доступе.
Как уже отмечалось, я не рекомендую смешивать две объектные модели в заданномодно приложение, поскольку это только сбивает с толку.
edit:
Цитировать по этой ссылке: https://docs.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/container-object-dao
Каждый объект базы данных имеет контейнерыколлекция, состоящая из встроенных объектов-контейнеров.Приложения могут определять свои собственные типы документов и соответствующие контейнеры (только базы данных ядра базы данных Microsoft Access);однако эти объекты не всегда могут поддерживаться через DAO.
Некоторые из этих объектов-контейнеров определяются ядром базы данных Microsoft Access, а другие могут быть определены другимиПриложения.В следующей таблице перечислены имена каждого объекта-контейнера, определенного ядром базы данных Microsoft Access, и тип информации, которую он содержит .