## Introduction

ODBC and SQL are established standards. The problem is, that ODBC doesn't specify the wire protocol and for some databases no ODBC driver exists. You might use RPC, TCP/IP, or shared memory and signals to pass the request from the client to the server. So you have to use the database specific ODBC library. This library might not be available for the CPU or operating system on which the client is running.

SQL itself is also not standardised enough, so that source compatibility can not be assured for all database servers. And for some sort of servers, SQL is not even feasible (think about LDAP).

GDA (GNOME Data Access) tries to tackle the ODBC problem and help you with the SQL problem. It's a sort of middleware (or can be blown up to be a middleware layer) to access different data sources. It offers a high level view of data sources and has some places where you can plug in low level access to the database for special tasks.

It offers a wrapper around the database internals, thus making it easier for programmers to make use of all the power provided by many RDBMS without even knowing about it. It comes along with a library, for both clients and servers, as a C implementation of this architecture. This level of abstraction would make possible to, at a later time, change all the internals without having to modify applications using the libraries.

Along with these libraries (and associated header files and language bindings for development), Libgda includes several tools and utilities to help you with the task of developing applications based on Libgda, as well as for automating some database-related tasks.

Libgda is implemented for `UNIX` -like operating systems (including `Linux`), and does not depend on other libraries apart from `libxml2` and `Glib`, which makes it a very lightweight system also ideal for applications to be run on hardware-limited systems.