This section presents the main features of the 5.2 version of Libgda.

Libgda is a low-level database abstraction layer built on top of each database C API. In terms of abstraction, Libgda offers the following top features:

  • Open a connection to any database which type is supported using either a defined data source (defined per user or system wide) or directly providing connection parameters. Several connections can be opened at the same time.

  • Run any SQL query against an opened connection; furthermore any SQL query can be extended to define query parameters using an easy to understand notation. If the SQL query was a SELECT statement, then an array of data is returned (as a GdaDataModel object), and otherwise the number of rows affected by the query is returned. For very large data sets, it is possible to specify that the returned array of data should be based on a cursor to avoid loading it into memory .

  • Perform most of the data definition queries (including database creation) for the database types which support it using a key/value mechanism.

  • Create, maintain and extend a view of the database's structure and meta data including the definitions of the tables, constraints, data types, .... It is defined as closely as possible to the information schema SQL standard (ISO/IEC 9075); see the Dictionary - metadata section for more information.

  • Easy to extend data models for custom requirements

  • Support for binary data and for BLOBs in a transparent way, see the Gda value section

  • Support for detailed parameters in SQL queries, see the GdaSqlParser object

  • Support for virtual connections, see the Virtual connections chapter

  • Partially thread-safe, see the threads limitation for more details

The database types which can be accessed at the time of writing are the following ones:

  • Access (.MDB files): uses the MDB Tools library to access the .MDB files, and is limited to getting information about tables and running very simple SELECT queries;

  • Firebird: compiles, needs testing;

  • MySQL: fully functional;

  • Oracle: work is progress, usable;

  • PostgreSQL: fully functional;

  • SQLite: fully functional;

  • Oracle Berkeley DB: fully functional;

  • Oracle Berkeley DB with SQL: fully functional;

  • SQLCipher: fully functional;