Data Access Manager
Encyclopedia
The Data Access Manager 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
, use 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 systems were expected to convert data to and from the system's respective 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 users, both application users and programmers writing those applications. One particularly notable feature was the concept of "query documents". Query documents contained any number of pre-defined queries (or other server commands), along with optional code to modify them before being sent to the server. For instance, a typical query document might contain a "query" that would log into the database server, and if that was successful, look up the current date from the local client machine using a Mac OS call, and then use that date in a query that returns inventory in a warehouse for a given 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 resource inside 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 similar to using query documents, although it was expected that the application would construct the queries in code rather than resources. The High Level interface is broadly similar to ODBC's public interface. Low Level allowed the programmer to intercede 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 relatively 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 a SQL server. For serverless sources, such as text files, a local SQL parser would interpret the commands and read the file. 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 in practice. Since it was expected that DAL would be providing query standardization, DAM had no layer similar to ODBC's for translating different dialects. 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 DAM's overall 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. Nor were any simple interfaces for text files or similar data sources included with basic DAM installs.
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.
Database
A database is an organized collection of data for one or more purposes, usually in digital form. The data are typically organized to model relevant aspects of reality , in a way that supports processes requiring this information...
access API for the Mac OS
Mac OS
Mac OS is a series of graphical user interface-based operating systems developed by Apple Inc. for their Macintosh line of computer systems. The Macintosh user experience is credited with popularizing the graphical user interface...
, introduced in 1991 as an extension to System 7
System 7 (Macintosh)
System 7 is a single-user graphical user interface-based operating system for Macintosh computers. It was introduced on May 13, 1991 by Apple Computer. It succeeded System 6, and was the main Macintosh operating system until it was succeeded by Mac OS 8 in 1997...
. 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
Mac OS X
Mac OS X is a series of Unix-based operating systems and graphical user interfaces developed, marketed, and sold by Apple Inc. Since 2002, has been included with all new Macintosh computer systems...
, use 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 systems were expected to convert data to and from the system's respective 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 users, both application users and programmers writing those applications. One particularly notable feature was the concept of "query documents". Query documents contained any number of pre-defined queries (or other server commands), along with optional code to modify them before being sent to the server. For instance, a typical query document might contain a "query" that would log into the database server, and if that was successful, look up the current date from the local client machine using a Mac OS call, and then use that date in a query that returns inventory in a warehouse for a given 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
Resource fork
The resource fork is a construct of the Mac OS operating system used to store structured data in a file, alongside unstructured data stored within the data fork. A resource fork stores information in a specific form, such as icons, the shapes of windows, definitions of menus and their contents, and...
, and ran each query resource inside 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 similar to using query documents, although it was expected that the application would construct the queries in code rather than resources. The High Level interface is broadly similar to ODBC's public interface. Low Level allowed the programmer to intercede 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
Data Access Language
Data Access Language, or simply DAL, was a SQL-like language parser released by Apple Computer in 1990 to provide unified client/server access to database management systems. It was known for poor performance and high costs, something Apple did little to address over its short lifetime at Apple....
, 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 relatively 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
X/Open
X/Open Company, Ltd. was a consortium founded by several European UNIX systems manufacturers in 1984 to identify and promote open standards in the field of information technology. More specifically, the original aim was to define a single specification for operating systems derived from UNIX, to...
(now part of the Open Group). Under OBDC every data source was made to look like a SQL server. For serverless sources, such as text files, a local SQL parser would interpret the commands and read the file. 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 in practice. Since it was expected that DAL would be providing query standardization, DAM had no layer similar to ODBC's for translating different dialects. 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 DAM's overall 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. Nor were any simple interfaces for text files or similar data sources included with basic DAM installs.
One of the major clients for DAM was HyperCard
HyperCard
HyperCard is an application program created by Bill Atkinson for Apple Computer, Inc. that was among the first successful hypermedia systems before the World Wide Web. It combines database capabilities with a graphical, flexible, user-modifiable interface. HyperCard also features HyperTalk, written...
, Apple's data manager/rapid application development
Rapid application development
Rapid application development is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself...
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
Baskin-Robbins
Baskin-Robbins is a global chain of ice cream parlors founded by Burt Baskin and Irvine Robbins in 1953, from the merging of their respective ice cream parlors, in Glendale, California. It claims to be the world's largest ice cream franchise, with more than 5,800 locations, 2,800 of which are...
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
Oracle Corporation
Oracle Corporation is an American multinational computer technology corporation that specializes in developing and marketing hardware systems and enterprise software products – particularly database management systems...
immediately purchased PLUS from Spinnaker Software
Spinnaker Software
Spinnaker Software was a 1982 founded software company known primarily for its line of non-curriculum based educational software, which was a major seller during the 1980s. It was founded by chairman Bill Bowman and president C. David Seuss....
, releasing it first as Oracle Card, and then Oracle Media Objects
Oracle Media Objects
Oracle Media Objects, formerly Oracle Card, was a multi-media software development tool for developing multi-media applications, with similar functionality and appearance to Apple Computer' HyperCard....
. 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
Mac OS X
Mac OS X is a series of Unix-based operating systems and graphical user interfaces developed, marketed, and sold by Apple Inc. Since 2002, has been included with all new Macintosh computer systems...
. 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
IODBC
iODBC is an open source initiative managed by OpenLink Software. It is a platform-independent ODBC SDK and runtime offering that enables the development of ODBC-compliant applications and drivers outside the Windows platform...
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
Core Data is part of the Cocoa API in Mac OS X first introduced with Mac OS X 10.4 Tiger and for iOS with iPhone SDK 3.0. It allows data organised by the relational entity-attribute model to be serialised into XML, binary, or SQLite stores. The data can be manipulated using higher level objects...
. Core Data allows developers to serialize data into SQLite
SQLite
SQLite is an ACID-compliant embedded relational database management system contained in a relatively small C programming library. The source code for SQLite is in the public domain and implements most of the SQL standard...
for processing, similar in concept to ODBC when used with a non-SQL data source.