Data Access Manager
The Data Access Manager (DAM) was a database access system for the "classic" MacOS, introduced in 1991 as an extension to System 7. Similar in concept to ODBC, DAM saw little use and was eventually dropped in the late 1990s. Only a handful of products ever used it, although it was used for some extremely impressive demoware in the early 1990s.
DAM and ODBC are similar in many ways. The primary purpose of both systems was to send "query strings" to a data provider, who would respond (potentually) with a result set consisting of rows of data. Both provided a communications subsystem that hid the details of sending queries and data between the client and server, although given the time that it was written, it should not be surprising that DAM supported a smaller number of networking systems. Additionally, both systems provided various API's for receiving and processing the result sets into local data formats, integers and strings for instance.
Like most Apple software, DAM attempted to make the query process as easy as possible for the end user. One particularily notable addition in this respect was the concept of query documents. Query documents contained any number of "pre-rolled" queries, along with optional code to modify them before being sent to the server. For instance, a typical query document might contain a "query" to log into the database server, then ask the user for a date, finally running a profit and loss statement for that date. The document could include computer code and resources needed for this process, for instance, a dialog box asking for the username and password.
Applications could use query documents without having any idea of the internals of the query. They simply opened the document, which consisted of a series of resources, and run each query in turn. The DAM would ensure that any needed code in the document would be run without the application even being aware, and eventually results would be passed back. The entire operation was opaque, allowing applications to add DAM support with ease.
One major difference between DAM and ODBC came about largely by accident. Prior to the development of DAM, Apple had purchased a database middleware product they sold as the Data Access Language, or DAL. DAL was essentially a standardized SQL, which did not really exist at the time, with translators for various databases that ran on the server side. Client software, including DAM, could send queries in DAL's standard language, which would then execute regardless of the back-end database.
Unfortunately this made DAM as a whole less attractive. Since it was expected that DAL would be providing query standardization, DAM had no such layer. Therefore in order for DAM to be truly useful, the user also had to buy and install a DAL server for their particular database. DAL was generally known to be slow and expensing, seriously degrading its value. Had DAM been written independantly of DAL it is likely it would have used a more ODBC-like solution, doing the conversion locally on the client side would have lowered cost, likely improved performance, and generally made the system much easier to deploy.
One of the major clients for DAM was HyperCard's, Apple's own rapid application development system that they ended up with largely by mistake. Combining HyperCard's excellent forms with data from DAM resulted in something that no-one had ever seen before, data-driven GUI apps. The most common demo of the system showed a HyperCard stack querying a series of Baskin Robins databases, formerly impossible because each regional area used their own database servers which DAL now combined into one. Reorders for stock could be made by dragging a series of ice cream scoops on a graphical display of the current warehoused inventory.
The system was so impressive that it made other database vendors scramble to provide similar systems; Oracle immediately purchased PLUS from Spinnaker Software, releasing it first as Oracle Card, and then Oracle Media Objects. Other companies followed similar routes, and soon the event-driven database front-end was a standard feature of most systems.
Oddly, Apple has had no standardized data access layer for some time. Work on DAM ended in the mid-90's, and disappeared entirely in MacOS X. This is being addressed in newer released of OS X, starting with 10.4 "Tiger", which includes a very powerful high-level system known as Core Data. However, Core Data is an entirely different concept than DAM or ODBC, more of an object-relational mapping system than a database pipe, a layer which Apple continues to lack.