Этот вопрос, на мой взгляд, на самом деле не опубликован добросовестно - он полностью адресован мне и комментариям, которые я делаю в ответ на ваши комментарии. Я уже ответил на все вопросы в другом месте, но чтобы прояснить ситуацию, позвольте мне рассказать об истории Jet.
Jet был представлен в начале 90-х вместе с Access. Между версиями 1 и 2 MS приобрела Foxpro и внедрила свою технологию «Rushmore» в Jet. Где-то в течение этого периода времени MS разработала DAO в качестве интерфейсного уровня для Jet. Я не знаю наверняка, что DAO когда-либо существовал как нечто иное, как уровень интерфейса данных, который использовал Jet для всего доступа к данным, но мне это показалось так. Jet был довольно хорошим выбором для этого, так как с ODBC и устанавливаемыми ISAM, он мог заставить практически любой из распространенных тогда форматов баз данных выглядеть и вести себя в вашем приложении так же, как выглядели и вели себя нативные данные Jet. В те времена на рынке настольных баз данных доминировали dBase и его варианты, а также Paradox. Это были все настольные базы данных, а не серверные базы данных. Доступ к базам данных сервера, как правило, осуществлялся через ODBC, но в то время это было не так важно для разработчиков приложений для настольных ПК. Jet неплохо справился с подключением к источникам данных ODBC и использовал их довольно эффективно, хотя иногда он допускал ошибки (и именно поэтому ODBCDirect был введен в Jet, что обошло бы некоторые аспекты механизма обработки данных Jet).
Теперь, параллельно с ростом Access / Jet / DAO, Visual Basic был горячим продуктом для общей разработки приложений для Windows, а до расцвета Интернета VB был наиболее широко используемым языком программирования в мире. DAO и Jet предоставили разработчикам VB интерфейс для всех видов хранилищ данных, и инструменты разработки VB были хорошо интегрированы с ними. Таким образом, после ODBC DAO стал ключевым уровнем интерфейса данных MS, использующим движок Jet для работы со всеми видами данных.
Естественно, у этого были свои проблемы, и он также был очень ограничен в том, что Jet / DAO (и VB) были инструментами, ориентированными на десктоп. К середине-концу 90-х MS пыталась перейти от поставщика настольных программ, настольных ОС и средств разработки к поставщику корпоративного программного обеспечения. Поэтому MS необходимо было разработать более надежные интерфейсы данных, что-то вроде ODBC для серверов баз данных, но со всеми современными функциями, которые предлагали более новые серверные базы данных. OLEDB был ответом на это с ADO в качестве интерфейсного уровня поверх OLEDB (точно так же, как DAO является интерфейсным уровнем поверх Jet). В то время как цель DAO состояла в том, чтобы обеспечить доступ ко многим хранилищам данных через ядро базы данных Jet, OLEDB был более нейтральным уровнем интерфейса данных, таким как ODBC, уровень абстракции базы данных, а ADO был интерфейсом к этому нейтральному уровню интерфейса данных.
По вопросу о "нативном" DDL факт, что до Jet 4 была очень плохая поддержка SQL DDL. То есть были функции Jet, которые нельзя было контролировать с помощью SQL DDL. Вместо этого вам пришлось использовать DAO для управления этими функциями. Несмотря на то, что в состав Jet Engine Engine включены примеры DDL наряду с примерами DAO, примеры DAO могут сделать намного больше, потому что Jet DDL SQL никогда не поддерживал все функции баз данных Jet.
Расстройство, которое кажется таким запутанным, произошло из-за внутренней политики РС. К 1999 году, когда MS представила Access 2000 (с новой версией Jet, 4.0), MS хотела отказаться от DAO в пользу ADO. MS сделала ADO уровнем интерфейса данных по умолчанию в Access, даже если не имело смысла использовать ADO (т. Е. Хранилище данных было Jet). В рамках этих усилий MS не полностью обновила DAO, чтобы включить поддержку всех новых функций Jet 4 - вместо этого они приложили свои усилия в ADO. Результатом стало то, что нативный уровень интерфейса данных Jet, DAO, не имел поддержки функций Jet, которые предлагал нейтральный уровень интерфейса базы данных, ADO. Это была, на мой взгляд, особая форма придурковедения со стороны Microsoft. MS намеренно не обновляла нативный интерфейсный уровень Jet, чтобы заставить вас использовать не нативный интерфейс. Таким образом, вместо DAO-> Jet, вам пришлось использовать ADO-> OLEDB-> Jet, даже для некоторых вещей, которые были нативными аспектами ядра базы данных Jet (например, некоторые типы данных для полей).
Цель Microsoft состояла в том, чтобы полностью уничтожить DAO и действительно уничтожить сам Jet. Они хотели, чтобы клиенты перешли на SQL Server.
Но произошло несколько вещей. С одной стороны, ADO, основанный на COM, не очень хорошо вписывался в .NET, и поэтому классический ADO на основе COM оказался заброшенным, и ADO.NET был создан, чтобы занять его место. Сходства между ADO и ADO.NET довольно поверхностны и основаны на совершенно разных моделях взаимодействия данных: ADO.NET почти полностью разрабатывался вокруг идеи отключенных данных, в то время как ADO не был (хотя он определенно поддерживал определенные виды отключенных доступ к данным).
С выходом ADO из окна у MS была дыра в середине линейки продуктов. Классический VB-разработчик или Access-разработчик не увидит большого преимущества в .NET, потому что вся модель доступа к данным не подходит. Таким образом, к выходу Access 2002 MS изменила курс и вернула DAO на свое место в качестве уровня интерфейса данных по умолчанию для данных Jet (и во всех других хранилищах данных, с которыми Jet мог работать, например, через ODBC и т. Д.). К сожалению, в то время как MS в настоящее время осуждает ADO для использования с Jet, они не решили исправить искаженную версию DAO, которая шла вместе с ней. Возможно, они этого не сделали, потому что к этому моменту было принято решение превратить существующий Jet 4 в ядро базы данных, принадлежащее группе разработчиков Access. Это в конечном итоге стало ACE и, по сути, Jet 4.5. Была выпущена новая версия DAO (хотя и замаскированная под легким в использовании именем «Библиотека объектов ядра базы данных Microsoft Office 12.0 Access», а имя DLL теперь ACEDAO.DLL). Я не знаю, в какой степени функции, отсутствующие в DAO 3.6 (версия Jet 4), были добавлены в ACE-версию DAO. Я не знаю, потому что мне не нужны какие-либо из этих функций, поэтому я даже не знаю, что это такое.
В любом случае, на данный момент, в настоящее время идет разработка для Jet (нам обещали, что Jet 4 был концом) и для собственного уровня интерфейса данных (DAO, который нам также обещали был мертв). Эта текущая разработка в настоящее время находится в группе приложений Access в Microsoft (в отличие от Windows, где ранее поддерживался Jet 4).
Microsoft добавила режимы совместимости в Access для использования так называемого режима SQL ANSI-92. Это должно позволить вам писать SQL, который «совместим» с SQL-диалектом SQL Server. Ну, он поддерживает несколько вещей (вы можете использовать подстановочные знаки SQL Server и использовать () для производных таблиц вместо винта Jet []. Как псевдоним), но не очень близко к TSQL. Но вне Access единственный способ использовать этот режим SQL «ANSI-92» - это использовать ADO для подключения к Jet. Сам DAO по-прежнему использует старый диалект SQL в Jet. Это показывает, что Jet не обеспечивает поддержку самого этого режима, но он предоставляется слоями выше Jet.