从一开始，开发软件应用程序就是为了访问某种数据库。分布式应用程序和基于 web 的应用程序也不例外。然而在分布式方案中，由于可能存在不同的硬件和软件平台或对象模型，事情变得稍微有点复杂。尽管如此，数据就是数据，在几乎任何地方都需要得到交换和处理。
在我们进入可编程 web 时代 — internet 的第三个阶段 — 之前，数据访问曾是一个相对简单的问题；主要关心的问题就是选择效能成本最合算的数据库服务器。任何系统的所有模块都必须符合数据库服务器 — 一种对整个系统进行完全控制的全能实体 — 的要求。客户机/服务器应用程序一直是这种模型的典型表现形式。
近来，n 层 microsoft® windows® dna 系统致力于开发能够对几乎任何种类的数据进行迅捷可靠的访问的技术，这些数据种类包括：关系型、非关系型、层次型、半结构化型、分散型、易失型等。这种数据访问的统一方法成为“通用数据访问”策略 — ole db 体系结构的鼓舞人心的原则。microsoft activex® data objects (ado) 的出现完成了一项重大的任务：将成千上万的 windows 开发人员从过时的客户机/服务器模型带到数据访问组件和 ole db 的奇妙世界。
在 windows dna 模型中，中间层组件通过 ole db 规范体贴地为我们定义的一种公用格式来获取和交换数据。这种格式以行集格式为基础，并且通常被转换为诸如 ado 记录集之类的一种更高级的结构。
使用 ado 记录集有得有失。一方面，它们提供了一种丰富并具有吸引力的编程接口。另一方面，它们是严格基于 com 的，在涉及许多平台（尤其是非 windows 平台）的分布式异构环境中无法使用。互操作性和可伸缩性是对现代 web 系统的两个很高的要求；互操作性和可伸缩性更好的数据访问体系结构同样是最新的 ado 版本 ado+ 中的主要变化。
ado 记录集的灵活性足以使您能够毫不费力地定位记录以及使用过滤器和书签。它们还提供排序、自动分页和持久性等功能，并能在与数据源断开时工作。可以在多层之间相当高效地汇集记录集，这归功于其固有的并且极为紧凑的二进制格式 — advanced data table gram (adtg) 格式。
断开的记录集在组件之间的传输涉及到 com 汇集，并强制接收组件配合这一汇集。换句话说，只有 com 对象才能使用 ado 记录集。这在 com/dcom 在业务层中占主导地位的同构体系结构中不成问题。显然，当有关的服务器端组件的映射涉及到诸如大型机或 unix 平台之类的异构节点时，就会带来很大的不便。
所谓的 internet 的第三个阶段使这一方案离我们更近了。它预示了一个世界，在这个世界中，功能实现通过各种 web 服务（即可以通过 http 访问的环绕着我们的卫星系统）成为可能。您将需要向这些服务中的某个传递一些记录以进行进一步处理，这个方案并不是什么勉强的事情。没有什么比 web 服务更加容易的事了 — 不管它的内部体系结构或公共编程接口如何 — 它不接受 ado 记录集。
a目前现实中的 ado，特别是记录集，是在 windows 和基于 com 的方案中操纵数据的强有力的工具。不幸的是，随着您的系统逐渐向完全的 internet 互操作性方向演变，它们逐渐丧失了其吸引力。
