OLE DB
OLE DB (англ. Object Linking and Embedding, Database , иногда записывается OLEDB, OLE-DB) — набор COM-интерфейсов, которые позволяют приложениям унифицировано работать с данными разных источников и хранилищ информации. Разработана Microsoft в качестве дальнейшего развития технологии доступа к данным и должен был прийти на замену и в качестве преемника ODBC, расширяя набор функций для поддержки более широкого круга нереляционных источников данных, таких как объектно-ориентированные базы данных или электронные таблицы, и для которых не обязательно использовать SQL.
OLE DB отделяет хранилище данных от приложения, которое должно иметь доступ к нему через набор абстракций, состоящий из источника данных (DataSource), сессии (Session), команды (Command) и набора строк (Rowset). Это было сделано для предоставления унифицированного доступа к различным видам и источникам данных и изоляцию специфики взаимодействия с конкретным хранилищем. OLE DB концептуально разделена на потребителей (клиентов) и поставщиков (провайдеров). Потребителем является приложение, которому необходим доступ к данным, а поставщик реализует интерфейс доступа к данным и, следовательно, обеспечивает информацией потребителя.
SQL Server Destination vs OLE DB Destination — SSIS Interview Questions
Спецификация OLE DB является частью Microsoft Data Access Components (MDAC), представляющей собой группу технологий Microsoft, формирующих основу для единого и всеобщего способа разработки приложений для доступа к данным практически любого хранилища. В состав MDAC входят, к примеру, сервисы OLE DB (пул подключений и прочее) и компоненты ADODB.
Провайдеры OLE DB могут предоставлять доступ как к простым хранилищам данных, в виде текстовых файлов и электронных таблиц, так и к «настоящим» базам данных под управлением Oracle Database, Microsoft SQL Server, Sybase ASE, Firebird и Interbase. Также возможен доступ и к иерархическим хранилищам данных таких, как системы электронной почты.
Поскольку различные хранилища данных могут иметь разные возможности, поставщики OLE DB, как правило, не поддерживают все интерфейсы, описанные в спецификации OLE DB. Доступные возможности поставщика данных определяются через запрос указателей на COM интерфейсы его объектов или через чтение информационных свойств источника данных (DataSource). Отметим, что поставщик данных может реализовывать и предоставлять свои собственные COM-интерфейсы и структуры данных, не описанные в спецификации OLE DB.
Существует устойчивое мнение, что OLE DB ориентирован в большей степени на MS SQL, однако это не так. Типы данных «массивы» и несколько параллельных транзакций в рамках одного подключения, поддерживаемых спецификацией OLE DB, в MS SQL не поддерживаются, но присутствуют в других серверах баз данных (Firebird, Interbase). Если и есть некая «ориентированность», то она распространяется только на операционную систему. Поскольку OLE DB основано на COM-технологии, а полноценная поддержка COM есть только в Windows, то OLE-DB-провайдеры существуют только для операционных систем семейства Windows.
Решение проблем совместимости Microsoft Access 2019 и Visual Studio 2022.
Долгое время Microsoft рекомендовала использовать OLE DB взамен ODBC, но с анонсом Microsoft SQL Server 2014 было объявлено [1] , что прекращается поддержка «родного» OLE DB для этого продукта и остаётся только поддержка ODBC. Скорее всего это относилось к «чистому» OLE-DB-провайдеру для MSSQL (SQLOLEDB), а не к «Native SQL Client» (SQLNCLI), в котором были объединены провайдеры OLE DB и драйверы ODBC. Однако со стороны это выглядело как полный отказ от OLE DB как от технологии. В октябре 2017 года было объявлено об ошибочности этого решения и анонсирован выпуск обновленного OLE DB провайдера для MSSQL [2] .
Источник: wiki2.org
OLE DB или ODBC? Семь раз отмерь.
OLE DB и ODBC представляют собой интерфейсы приложений, которые обеспечивают доступ к целому ряду источников данных.
Разработчики Microsoft спроектировали ODBC для доступа к данным SQL, а OLE DB — для доступа к любым данным в среде СОМ.
Одни пользователи до сих пор не понимают, что же послужило причиной внедрения OLE DB, другие переоценивают роль OLE DB в области корпоративных и ориентированных на Internet разработок. В данной статье мне хотелось бы не только объяснить, зачем компании Microsoft понадобилось вводить OLE DB, но и оценить ту роль, которую это средство играет сегодня и, что гораздо важнее, будет играть завтра. Думаю, моя статья заинтересует в первую очередь опытных разработчиков, использующих ODBC и желающих иметь представление об OLE DB.
Чем же плох ODBC?
Внедрение OLE DB не означает отказ от ODBC. В обозримом будущем Microsoft планирует поддерживать ODBC так же, как это делают другие производители СУБД и инструментальных средств. Так чем же не устраивает разработчиков ODBC? Для доступа к данным он вполне адекватен. Опыт подтверждает, что, если ODBC удовлетворяет потребности вашего бизнеса, об OLE DB и связанных с ним технологиях пока можно забыть.
Однако ODBC превратился в развитую, полностью выразившую себя технологию, и Microsoft не будет далее его совершенствовать. ODBC подобен поезду, следующему в депо, до которого осталось всего несколько остановок. На любой остановке можно пересесть на другой поезд, OLE DB, и каждый сам решает, когда это лучше сделать.
Таким образом, ODBC вполне справляется со своими обязанностями. Хорошо известна его производительность, гибкость и архитектура. Существует немало различных инструментальных средств и рабочих сред, построенных на ODBC (например, RDO).
Чтобы понять, как скоро предстоит задуматься о переходе к OLE DB, проанализируйте, в какой степени возможности ODBC соответствуют тем усовершенствованиям, которые планируется внедрить в вашей информационной системе. При этом нужно помнить о том, что в течение ближайших пяти лет ODBC будет предоставлять те же самые возможности, что и сегодня. ODBC будет по-прежнему обеспечивать доступ к данным SQL, которые не интегрированы с другими, нереляционными типами данных, такими, как файлы языка XML, документы Microsoft Office или файлы электронной почты. Если же подобного рода файлы являются частью информационных ресурсов компании, стоит рассмотреть вариант OLE DB.
Что нового предлагает OLE DB
OLE DB представляет собой следующую ступень развития ODBC. Эти средства образуют относительно независимый программный слой, использующий один и тот же набор основных интерфейсов прикладных программ (API) для доступа к разнообразным базам данных.
Их работа обеспечивается невидимыми для пользователя программными модулями, которые учитывают специфические особенности каждой СУБД и выступают в качестве драйверов для верхних программных слоев. В OLE DB полностью реализован принцип открытости связей между базами данных. Наибольшие различия проявляются в использовании некоторых основных терминов и в окружающем контексте. В Таблице 1 содержатся трактовки часто употребляемых терминов применительно к ODBC и OLE DB.
Таблица 1. Интерпретация основных терминов в ODBC и OLE DB.
С точки зрения функциональности OLE DB обеспечивает доступ ко всем типам информации: реляционным и нереляционным, плоским и иерархическим, постоянным и переменным, ориентированным на SQL или на любой другой язык запросов. Для облегчения доступа к информации источники данных OLE DB представляются компонентами, базирующимися на СОМ, с четко определенным программным интерфейсом.
Эти компоненты, называемые поставщиками данных, взаимодействуют с хранилищем информации. При соединении с поставщиком данных клиентское приложение всегда получает в качестве ответа набор записей независимо от того, к чему обращается поставщик данных — к таблице реляционной СУБД или к листингу каталога. Поставщик отвечает за извлечение данных с физического носителя и их форматирование. Данные могут храниться в одном и том же постоянном месте (в файлах на диске или в базе данных), в определенной области памяти или даже на разных машинах и разных платформах. Они могут быть реляционными и иерархическими, структурированными и плоскими, записанными в стандартном и в частном формате, доступными и недоступными для ODBC.
Возвращаемый OLE DB результирующий набор (называемый набором строк или записей) представляет собой не просто поток байтов, записываемых в память клиентского приложения, как в случае ODBC. Этот поток данных содержится в независимом модуле СОМ с отдельным программным интерфейсом. Такой модуль предлагает различные способы манипулирования набором записей — сортировку, фильтрацию, прокручивание текста. При этом он допускает возможность одновременной работы с данными многих пользователей. Работать с набором строк можно даже при отключении от первоначального источника данных, что делает тем самым этот новый мощный тип данных весьма эффективным.
Преграды на пути OLE DB
Так ли уж хорош OLE DB? Для ответа на этот вопрос следует тщательно изучить два аспекта. С одной стороны, OLE DB нельзя назвать вполне зрелой технологией. С другой — Microsoft позиционирует его как базовый сервис доступа к данным для будущих платформ Windows. Это означает, что в Microsoft планируют существенно доработать OLE DB.
Рассмотрим эти два аспекта более подробно, чтобы попробовать предсказать, какое влияние они окажут на пользователей.
Microsoft предлагает OLE DB в качестве основной технологии доступа к данным для Visual Studio 97. Версия OLE DB 2.5, которую предполагается выпустить вместе с Windows 2000, дебютировала в TechEd 99. Множество изменений, внесенных со времени выхода первой версии, казалось бы, говорят о нестабильности технологии. Однако в начале 1990-х такое же впечатление производила и технология ODBC.
Тем не менее уже начиная с версии 3.0 ODBC работает прекрасно, и сегодня разработчики расценивают ее как очень стабильную технологию. Но это потребовало времени. Поскольку данные представляют собой «стратегическое горючее» для большинства компаний, необходимо особенно тщательно прорабатывать любые технологии, влияющие на доступ к данным.
На Рисунке 1 приведены для сравнения архитектуры OLE DB и ODBC.
 |
| РИСУНОК 1. Архитектура ODBC и OLE DB. |
Обе базируются на специализированных компонентах (драйверах в случае ODBC и поставщиках в архитектуре OLE DB), которые соединяются с источником данных. В рамках ODBC драйвер обычно выступает в роли уполномоченного посредника, который передает команду SQL ядру СУБД, а обратно возвращает результирующий набор данных. Поставщик OLE DB принимает запросы на любом языке запросов (не обязательно на SQL) и возвращает наборы записей. Поставщик, инкапсулирующий СУБД, ограничивается простой передачей команд SQL нижестоящему серверу базы данных. Поставщик, взаимодействующий с нереляционным источником данных (например, с сообщениями электронной почты), выполняет дополнительную функцию: создает набор записей и наполняет его информацией. Такой поставщик мог бы работать с более простым языком запросов, чем SQL. Допустим, для возврата сообщения электронной почты от заказчика поставщику необходимо знать только имя отправителя. Команда типа
Sender = Joe User;
проста, эффективна и легко кодируется.
OLE DB состоит из двух частей: внешнего интерфейса и внутреннего ядра. Ядро, работающее в фоновом режиме, обрабатывает запросы и производит поиск данных. Часть OLE DB, отвечающая за внешний интерфейс, содержит программные средства, необходимые любому поставщику для взаимодействия с клиентами.
Только Microsoft может установить стандарт на развитие OLE DB с точки зрения функциональности и технологии. Для этой цели задается спецификация интерфейса СОМ, который поставщик должен поддерживать. OLE DB 2.5 демонстрирует значительный прогресс по сравнению с более ранними версиями: в ней сняты некоторые ограничения проектирования и добавлены новые возможности.
К примеру, OLE DB 2.5 позволяет возвращать нерегулярные, не табулированные наборы записей. OLE DB можно использовать для показа полуструктурированных и иерархических данных, таких, как потоки XML, документы Word и Excel, содержимое директории файловой системы. Кроме того, в новой версии уменьшается объем информации о поставщике, которую необходимо знать потребителю. Вместо спецификации сложных командных строк и строк соединения связаться с нужным набором записей можно посредством синтаксиса URL. Это свойство, называемое прямой URL-связью, позволяет написать такую строку соединения:
http://outlookprovider/inbox/sender=»Joe User»
В этой интуитивно понятной записи стоят имя поставщика данных outlookprovider и текст команды, предписывающей поставщику просканировать директорию inbox и найти все сообщения, отправленные абонентом Joe User. Последняя версия инструментария разработчика на платформе Microsoft, SDK (Software Development Kit), частично повторяет достижения OLE DB 2.5.
Поскольку разработчики Microsoft рассматривают OLE DB в качестве основной технологии доступа к данным в среде Windows, пользователи в обозримом будущем получат всю необходимую поддержку для применения OLE DB. Поставщики важнейшего продукта Microsoft в классе серверов баз данных, SQL Server, незамедлительно отразят в нем все нововведения OLE DB.
Воспримут ли эти новшества производители других баз данных? На мой взгляд, недостаток OLE DB в том, что его единственной надежной опорой являются производители SQL Server версий 6.5 и 7.0. Известно, что изготовители OLE DB для Jet и Oracle выпустили функционально неполные продукты, в которых обнаружены ошибки, так что разработчикам они вряд ли будут полезны.
Версия OLE DB для Oracle производства корпорации Microsoft тоже не поражает воображения, но тем не менее представляется наиболее приемлемой. Версия OLE DB 2.1 обеспечивает доступ к данным из множественных программных сред, но это пока еще проблематично. Для того чтобы технология OLE DB превратилась в стандарт, всем производителям баз данных и, возможно, независимым компаниям необходимо выпустить полные версии поставщиков данных для различных СУБД. Не исключено, что потребуется совместными усилиями совершенствовать эти компоненты.
В общем, OLE DB еще предстоит завоевать признание и получить репутацию надежного средства, т. е. повторить путь, проделанный за последние годы ODBC. Но OLE DB обладает достаточным потенциалом для того, чтобы превзойти ODBC по разнообразию поддерживаемых источников данных, гибкости и удобству программных интерфейсов. Более того, центральная роль OLE DB в архитектуре работающих под управлением Windows распределенных приложений для Internet, DNA (Distributed InterNet Applications), а также в архитектуре DNS делает эту технологию реальным кандидатом на место ODBC. По всей вероятности, OLE DB станет важным компонентом при планировании будущих стратегий доступа к данным. Но слепо применять ее не следует.
Когда стоит выбрать OLE DB
Если принимать решение относительно OLE DB предстоит уже сегодня, то на какие факторы следует обратить внимание? Разработчики Microsoft спроектировали OLE DB с учетом требований производительности, но с точки зрения архитектуры вызов OLE DB пересекает больше программных слоев, чем запрос SQL, запущенный непосредственно из кода через интерфейс API в ODBC. Поэтому при использовании ODBC процесс происходит немного быстрее. Чтобы компенсировать этот недостаток, разработчики предусмотрели следующую возможность: OLE DB позволяет агрегировать и интегрировать структурно различные типы данных и использовать их в Web-приложениях.
Нужно помнить о том, что перейти к OLE DB не так-то просто. Это предостережение актуально даже для тех пользователей, которые уже применяют объектную модель: RDO, или Data Access Object (DAO), или даже ADO версии более ранней, чем 2.х. Особенно сложным может быть переход в случае использования СУБД, отличной от SQL Server. Расходы при этом окупятся только тогда, когда начнется реальная эксплуатация преимуществ интеграции с приложениями и системными услугами, которые предоставляет OLE DB. Если пользователи не знают, как реализовать достоинства гетерогенных запросов, не задействуют хранилища данных и не планируют интегрировать нереляционные типы данных (документы, электронные таблицы, электронную почту), они рискуют потерять производительность! (Или не обнаружить конкретных улучшений после обновления системы.)
Обычно я советую своим клиентам переходить к OLE DB только тогда, когда это обусловлено насущными потребностями бизнеса (как описано выше). То же рекомендуется и при создании новых систем, так как в процессе проектирования можно сразу заложить в них все возможности, предоставляемые OLE DB. Гибкость, интеграция и однородность — важные качества OLE DB. Если они необходимы для бизнеса компании, то переход к OLE DB может стать экономически эффективным.
Системы, базирующиеся на Internet, представляют собой обширную область применения для OLE DB, хотя низкое качество услуг некоторых провайдеров способно дискредитировать все усилия. Для вызова удаленных компонентов через HTTP в сети Web можно использовать службы удаленного доступа к данным, Remote Data Services (RDS). Реализовать такую возможность позволяет применение в качестве ключевой технологии разработанных компанией Microsoft компонентов доступа к данным, Microsoft Data Access Components (MDAS), которые включают и OLE DB. Наконец, на клиентской стороне OLE DB предоставит для обработки отсоединенные наборы записей.
У OLE DB есть сильные и слабые стороны; эта технология не возникла по мановению волшебной палочки. Она проходит стадию совершенствования, чтобы со временем превратиться в признанный стандарт. Познакомиться с ней стоит сегодня, а применять — только тогда, когда вы будете готовы извлечь из этого конкретную пользу.
ОБ АВТОРЕ
Дино Эспозито специализируется на разработках сценариев для среды СОМ. Является автором справочника для программистов по написанию сценариев Windows Scripting Host Programmer?s Reference (Wrox Press); работает в Риме преподавателем и консультантом.
Источник: www.osp.ru
As oledb что это за программа
ODBC против OLEDB
Обычно программные приложения написаны на определенном языке программирования (таком как Java, C # и т. Д.), А базы данных принимают запросы на каком-либо другом языке, специфичном для базы данных (например, SQL). Поэтому, когда программному приложению требуется доступ к данным в базе данных, требуется интерфейс, который может переводить языки друг на друга (приложение и база данных).
В противном случае прикладным программистам необходимо изучить и включить языки, специфичные для баз данных, в свои приложения. ODBC (Open Database Connectivity) и OLEDB (Object Linking and Embedding, Database) — два интерфейса, которые решают эту конкретную проблему. ODBC — это интерфейс, не зависящий от платформы, языка и операционной системы, который можно использовать для этой цели. OLEDB является преемником ODBC.
Что такое ODBC?
ODBC — это интерфейс для доступа к системам управления базами данных (СУБД). ODBC был разработан SQL Access Group в 1992 году в то время, когда не существовало стандартной среды для обмена данными между базой данных и приложением. Это не зависит от конкретного языка программирования, системы баз данных или операционной системы. Программисты могут использовать интерфейс ODBC для написания приложений, которые могут запрашивать данные из любой базы данных, независимо от среды, в которой они работают, или типа используемой СУБД.
Поскольку драйвер ODBC действует как переводчик между приложением и базой данных, ODBC может обеспечить независимость от языка и платформы. Это означает, что приложение избавляется от бремени знания специфического языка базы данных. Вместо этого он будет знать и использовать только синтаксис ODBS, а драйвер переведет запрос в базу данных на понятном ему языке.
Затем результаты возвращаются в формате, понятном приложению. Программный API ODBC можно использовать как с реляционными, так и с нереляционными системами баз данных. Еще одно важное преимущество использования ODBC в качестве универсального промежуточного программного обеспечения между приложением и базой данных состоит в том, что каждый раз при изменении спецификации базы данных не требуется обновлять программное обеспечение. Достаточно только обновления драйвера ODBC.
Что такое OLEDB?
OLEDB — это API данных, разработанный Microsoft. Это позволяет получить доступ к данным из большого количества источников данных. Он реализован с помощью Microsoft COM (режим компонентных объектов). OLEDB считается преемником ODBC и может обрабатывать источники данных на гораздо более высоком уровне по сравнению с ODBC.
По сути, OLEDB расширяет возможности ODBC на нереляционные базы данных (например, объектные базы данных и электронные таблицы). Это означает, что OLEDB можно использовать с базами данных, которые не используют SQL. OLEDB был разработан как часть компонентов доступа к данным Microsoft (MDAC).
В чем разница между ODBC и OLEDB?
Если программист не знаком с COM, то ODBC — лучший вариант. Но ODBC подходит только для реляционных баз данных, а OLEDB подходит как для реляционных, так и для нереляционных баз данных. Если база данных не поддерживает OLE (среды, отличные от OLE), ODBC — лучший выбор. Если среда не является SQL, вам необходимо использовать OLEDB (поскольку ODBC работает только с SQL).
Аналогичным образом, если требуются совместимые компоненты базы данных, вместо ODBC необходимо использовать OLEDB. Однако для 16-битных данных доступ к ODBC является единственным вариантом (OLEDB не поддерживает 16-битные данные). Наконец, OLEDB — лучший выбор для одновременного подключения к нескольким базам данных (ODBC может подключаться только к одной базе данных одновременно).
Источник: ru.strephonsays.com
Лекции по АРМ произв. менеджера / Лекция SQL Server и Delphi / Лекция 5 Технология ADO работы с БД
Для организации в Delphi доступа к базам данных можно применять различные технологии. Раньше использовали механизм BDE. Это набор библиотек DLL для организации низкоуровневого доступа данным различных форматов. Достоинство: высокая скорость обработки, недостаток – сложность написания программного кода.
Технология ADO – это организация доступа к базам данных на высоком уровне. При этом технология не зависит от архитектуры баз данных, что является достоинством. Проигрыш в снижении скорости доступа данным.
Технология ADO и интерфейсы OLE DB обеспечивают для приложений единый способ доступа к источникам данных различных типов (рис 1). Например, приложение, использующее ADO, может применять одинаково сложные операции и к данным, хранящимся на корпоративном сервере SQL, и к электронным таблицам, и локальным СУБД. Запрос SQL, направленный любому источнику данных через ADO, будет выполнен.
Рис.1. Схема доступа к данным через ADO
Возникает вопрос: каким образом источники данных смогут выполнить запрос?
За серверы БД беспокоиться не стоит, обработка запросов SQL— основная обязанность. Но как быть с файловыми последовательностями, электронными таблицами, файлами электронной почты и т. д. Здесь на помощь приходят механизмы ADO и интерфейсы OLE DB.
OLE DB представляет собой набор специализированных объектов, инкапсулирующих стандартные функции обработки данных, и специализированные функции конкретных источников данных и интерфейсов, обеспечивающих передачу данных между объектами.
Согласно терминологии ADO, любой источник данных (база данных, электронная таблица, файл) называется хранилищем данных, с которым при помощи провайдера данных взаимодействует приложение. Минимальный набор компонентов приложения может включать объект соединения, объект набора данных, объект процессора запросов.
Приложение обращается не прямо к источнику данных, а к объекту OLE DB, который «умеет» представить данные (например, из файла электронной почты) в виде таблицы БД или результата выполнения запроса SQL..
Технология ADO в целом включает в себя не только сами объекты OLE DB, и механизмы, обеспечивающие взаимодействие объектов с данными и приложениями. На этом уровне важнейшую роль играют провайдеры ADO, координирующие работу приложений с хранилищами данных различных типов.
Такая архитектура позволяет сделать набор объектов и интерфейсов открытым и расширяемым. Набор объектов и соответствующий провайдер может быть создан для любого хранилища данных без внесения изменений в исходную структуру ADO. При этом существенно расширяется само понятие данных — ведь можно разработать набор объектов и интерфейсов и для нетрадиционных табличных данных. Например, это могут быть графические данные геоинформационных систем, древовидные структуры из системных реестров, данные CASE-инструментов и т. д.
Так как технология ADO основана на стандартных интерфейсах СОМ, которые являются системным механизмом Windows, это сокращает общий объем работающего программного кода и позволяет распространять приложения БД без вспомогательных программ и библиотек.
Провайдеры ADO
Провайдеры ADO обеспечивают соединение приложения, использующего данные через ADO, с источником данных (сервером SQL, локальной файловой системой и т. д.). Для каждого типа хранилища данных существовать провайдер ADO.
Провайдер «знает» о местоположении хранилища данных и умеет обращаться к данным с запросами и интерпретировать возвращаемую служебную информацию и результаты запросов с целью их передач приложению.
Список установленных в данной операционной системе провайдеров доступен для выбора при установке соединения через компонент TADOConnection.
При инсталляции Microsoft ActiveX Data Objects в операционной системе устанавливаются следующие стандартные провайдеры.
Microsoft Jet OLE DB Provider обеспечивает соединение с данными Access.
Microsoft OLE DB Provider for Internet Publishing позволяет использовать ресурсы, предоставляемые Microsoft FrontPage, Microsoft Information Server, НТТР-файлы.
Microsoft Data Shaping Service for OLE DB позволяет использовать иерархические наборы данных.
Microsoft OLE DB Simple Provider предназначен для организации доступа к источникам данных, поддерживающим только базисные возможности OLE DB.
Microsoft OLE DB Provider for ODBC drivers обеспечивает доступ к данным, которые уже «прописаны» при помощи драйверов ODBC. Однако реальное использование столь экзотичных вариантов соединений представляется проблематичным. Драйверы ODBC и так славятся своей медлительностью, поэтому дополнительный слой сервисов здесь ни к чему.
Microsoft OLE DB Provider for Oracle обеспечивает соединение с сервером Oracle.
Microsoft OLE DB Provider for SQL Server обеспечивает соединение с сервером Microsoft SQL Server.
Реализация ADO в Delphi
Механизм доступа к данным через ADO и многочисленные объекты и интерфейсы реализованы в Delphi в виде набора компонентов, расположенных на странице ADO. Все необходимые интерфейсы, обеспечивающие работу компонентов, объявлены и описаны в файлах OleDB.pas и ADODB.pas в папке DelphiASourceVcl.
Компоненты ADO
Компонент ADOConnection вобрал возможности перечислителя, источника и сессии с возможностями обслуживания транзакций. Находится на вкладке ADO.
Основным свойством является свойство ConnectionString. Оно устанавливает связь с хранилищем данных. После задания этого свойства используется свойство Active логического типа или метод Open (Close). Они устанавливают или разрывают связь с хранилищем данных. Для установления связи с хранилищем данных установить значение True или запустить метод Open.
Для разрыва связи установить значение False или запустить метод Close. Эти действия можно реализовать программно на этапе выполнения.
Другим компонентом является компонент ADOTABLE. Находится на странице ADO. Является аналогом компонента TABLE. Обслуживает данные, состоящие из записей одной таблицы БД. Имя таблицы указывается в свойстве TableName.
В свойстве Connection следует указать имя компонента ADOConnection1. Установление связи указывается в свойстве Active.
Компонент DATASOURСE (страница Доступ к данным) является промежуточным звеном между компонентом ADOTABLE и визуальными компонентами DBGRID и DBNAVIGATOR. В компоненте DATASOURСE следует в свойстве DATASET выбрать имя связующего компонента ADOTABLE.
Визуальный компонент DBGRID находится на странице Доступ к данным. Является аналогом рассмотренного ранее компонента STRINGGRID. Отображает содержимое таблицы в виде сетки. В нем строки соответствуют записям, а столбцы – полям таблицы базы данных. Для свойства DATASOURCE следует указать имя используемого промежуточного компонента DATASOURCE.
Компонент DBNAVIGATOR находится также на странице Доступ к данным. Организует перемещения по таблице базы данных. Для свойства DATASOURCE следует указать имя используемого промежуточного компонента DATASOURCE, т.е. настройка осуществляется как и для предыдущего компонента.
Организация работы с базой данных Ms Access
Создадим базу данных из трех связанных таблиц Клиенты, Товары, заказы. Созданную базу данных формата сохраним в текущей папке проекта Delphi.
Создадим в Delphi новый проект и на форме разместим рассмотренные ранее компоненты (рис. 1).
Рис. 1 Пример формы для работы с БД
Рассмотрим последовательность настройки компонентов.
Через двойной щелчок откроем окно настройки компонента ADOConnection1. Оно будет иметь вид рис. 2.
Рис. 2 Окно настройки компонента ADOConnection1
Далее щелкнем по кнопке Build…(создать связь с БД). Откроется следующее окно (рис. 3).
Рис. 3 Окно выбора провайдера услуг
Далее выберем в качестве провайдера выделенную строку. Через кнопку Далее перейдем к рис. 4.
Рис. 4 Окно связи с данными
Далее выберем путь и имя файла, в котором находится база данных. Отметим, что базы данных Ms Access хранятся в файлах с расширением mdb. Можно также указать сведения для входа в БД, т.е. логин и пароль..
Далее следует щелкнуть по кнопке Проверить подключение. В результате правильного соединения увидим следующее окно
На этом настройка компонента ADOConnection1 завершается.
Настройка компонента ADOTABLE1.
TABLENAME выбрать имя таблицы БД из списка таблиц
Настройка компонента DATASOURCE1
Настройка компонентов DBGRID1 и NAVIGATOR1
Затем следует проект сохранить и запустить на выполнение. В результате в компоненте DBGRID1 увидим данные выбранной таблицы базы данных. Далее можно редактировать значения полей таблицы.
Можно программно организовать доступ ко всем таблицам БД.
Источник: studfile.net