Data Access Manager
From Wikipedia, the free encyclopedia
The Data Access Manager (DAM) was a database access API for the Mac OS, 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. More modern versions of the Mac OS, notably Mac OS X, support ODBC for this role instead.
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 (potentially) with a result set consisting of rows of data. Both were expected to convert data from the remote provider into local formats, integers and strings for instance. Additionally, 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.
Like most Apple software, DAM attempted to make the query process as simple as possible for the end users, both application users and programmers. One particularly notable addition in this respect was the concept of query documents. Query documents contained any number of pre-rolled queries (server commands really), 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, and if successful, look up the current date using the Mac OS call, and then use that date in a query that returns inventory in a warehouse for a particular date. Query documents could also include computer code and resources needed to support 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 ran each query in turn. The DAM would ensure that any needed code in the document would be run without the application even being aware of it, and eventually results would be passed back to the application for display. The entire operation was opaque, allowing applications to add DAM support with ease.
DAM also included two more direct API's, the High Level interface, and the Low Level interface. High Level was fairly close to using query documents, although it was expected that the application would construct the queries internally. The High Level interface is generally similar to ODBC's public interface. Low Level allowed the programmer to interceed at any point in the query process, retrieving data line-by-line for instance.
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 with translators for various databases that ran on the server side (standards for SQL were extremely basic at the time, and rather poorly supported). Client software, including DAM, could send queries in DAL's standard language which would then be translated and executed regardless of the back-end database.
In contrast, ODBC was developed from the start to be a SQL-based system, based on the standardized Call-Level Interface from X/Open (now part of the Open Group). Under OBDC every data source was made to look like an SQL server. For serverless sources, such as text files, a local SQL parser would interpret the commands and read the file, pretending to be a SQL server. Under ODBC, all data source drivers are expected to understand SQL and translate it to the local dialect if needed, as well as convert data into standard formats when it is returned.
This difference made DAM much less useful than ODBC. 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 expensive, seriously degrading its value. Further, DAM did not standardize the language for accessing non-SQL data sources, an adaptor for a text file might use a non-SQL language, or a completely function-call based system instead. Had DAM been written independently of DAL it is likely it would have used a more ODBC-like solution; doing the translation 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, Apple's data manager/rapid application development system. Combining HyperCard's excellent forms system 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-Robbins 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 Corporation 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.
A number of other applications also used the system, perhaps ironically Microsoft's various Office products doing so with the most regularity. Other than that DAM support was fairly rare, and the product did not see widespread use. Perhaps much of this was due to the incomplete nature of the DAM system as a whole; the need for DAL middleware in most cases, and the lack of low-cost query document builders (there were some expensive ones) made the overhead of using DAM quite high.
Work on DAM ended in the mid-90's, and disappeared entirely sometime before the release of Mac OS X. A "classic" Mac OS version of ODBC was available for some time, although support was limited. Starting with the release of OS X 10.2 Jaguar, Apple started distributing a version of the iODBC cross-platform ODBC drivers.
Starting with OS X 10.4 Tiger Apple has introduced a new and much "higher level" system known as Core Data. Core Data allows developers to serialize data into SQLite for processing, similar in concept to ODBC when used with a non-SQL data source. ODBC is an entirely different concept than DAM or ODBC, more of an object-relational mapping system than a database pipe.
