to a specific query language (subset) and only have to implement a thin layer to reach their goal. As all SQL dialects are similar to one another, application developers can use all the language features, possibly providing configurable elements for database-specific cases, such as typically user-IDs and credentials. A thin-layer allows the same queries and statements to run on a variety of database products with negligible overhead. Popular use for database abstraction layers are among object-oriented programming languages, which are similar to API-level abstraction layers. In an object-oriented language like C++ or Java, a database can be represented through an object, whose methods and members (or the equivalent thereof in other programming languages) represent various functionalities of the database. They also share advantages and disadvantages with API-level interfaces. Language-level abstraction An example of a database abstraction layer on the language level would be ODBC that is a platform-independent implementation of a database abstraction layer. The user installs specific driver software, through which ODBC can communicate with a database or set of databases. The user then has the ability to have programs communicate with ODBC, which then relays the results back and forth between the user programs and the database. The downside of this abstraction level is the increased overhead to transform statements into constructs understood by the target database. Alternatively, there are thin wrappers, often described as lightweight abstraction layers, such as OpenDBX and libzdb. Finally, large projects may develop their own libraries, such as, for example, libgda for GNOME. Arguments In favor Development period: software developers only have to know the database abstraction layer's API instead of all APIs of the databases their application should support. The more databases should be supported the bigger is the time saving. Wider potential install-base: using a database abstraction layer means that there is no requirement for new installations to utilise a specific database, i.e. new users who are unwilling or unable to switch databases can deploy on their existing infrastructure. Future-proofing: as new database technologies emerge, software developers won't have to adapt to new interfaces. Developer testing: a production database may be replaced with a desktop-level implementation of the data for developer-level unit tests. Added Database Features: depending on the database and the DAL, it may be possible for the DAL to add features to the database. A DAL may use database programming facilities or other methods to create standard but unsupported