Configuring the SQL Interface
Prev | Chapter 6. Building Berkeley DB for UNIX/POSIX | Next

## Configuring the SQL Interface

There are a set of options you can provide to configure in order to control how the Berkeley DB SQL interface is built. These configuration options include:

--enable-sql
  Causes the dbsql command line interpreter to be built. Along with dbsql, this argument also builds the libdb_sqlXX.{so|la} library, a C API library that mirrors the SQLite C API.
--enable-sql_compat

  Causes the sqlite3 command line tool to be built. This tool is identical to the dbsql command line tool, except that it has the same name as the command line tool that comes with standard SQLite.

  In addition, the libsqlite3.{so|la} C API library is built if this option is specified. This library is identical to the libdb_sqlXX.{so|la} library that is normally built for Berkeley DB's sql interface, except that it has the same name as the library which is built for standard SQLite.

  ### Warning

  Use this compatibility option with extreme care. Standard SQLite is used by many programs and utilities on many different platforms. Some platforms, such as Mac OS X, come with standard SQLite built in because default applications for the platform use that library.

  Use of this option on platforms where standard SQLite is in production use can cause unexpected runtime errors either for your own application, or for applications and utilities commonly found on the platform, depending on which library is found first in the platform's library search path.

  Use this option only if you know exactly what you are doing.

  This option is provided so that there is an easy upgrade path for legacy SQLite tools and scripts that want to use BDB SQL without rewriting the tool or script. However, data contained in standard SQLite databases must be manually migrated from the old database to your BDB SQL database even if you use this option. See the Berkeley DB Getting Started with the SQL APIs guide for information on migrating data from standard SQLite to BDB SQL databases.

  Note that in addition to the renamed command line tool and library, this option also causes versions of the command line tool and library to be built that use the normal BDB SQLite names (dbsql and libdb_sqlXX.{so|la}).

--enable-test
  Cause the Berkeley DB SQL interface test suite to be built. This argument can also be used with either `--enable-sql` or `--enable-sql_compat` to build the SQLite Tcl test runner.
--enable-jdbc
  Causes the JDBC driver to be built.

The following configuration options are useful when debugging applications:

--enable-debug
  Builds the Berkeley DB SQL interface with debug symbols.
--enable-diagnostic
  Builds the Berkeley DB SQL interface with run-time debugging checks.

Any arguments that you can provide to the standard SQLite configure script can also be supplied when configuring Berkeley DB SQL interface.

### Changing Compile Options

- For Berkeley DB SQL to generate each table in a separate file, rather than as subdatabases in a single file, specify the BDBSQL_FILE_PER_TABLE flag as an argument to the configure script using the standard environment variable, CPPFLAGS. When this option is enabled, the SQL database name is used as a directory name. This directory contains one file for the metadata and one file each for every table created by the SQL API. Note that adding or deleting files from the database directory may corrupt your database. To backup the metadata (schema), make a copy of the `metadata` and `table00001` files from the database directory. Make a new copy whenever the schema is changed.
- For Berkeley DB SQL to set the default page size when you create a database, specify the BDBSQL_DEFAULT_PAGE_SIZE flag as an argument to the configure script using the standard environment variable, CPPFLAGS. The value assigned must be a 0, 512, 1024, 2048, 4096, 8192 16384, 32768, or 65536. The default value is 4096. If the value is set to zero, Berkeley DB queries the file system to determine the best page size, and the value of SQLITE_DEFAULT_PAGE_SIZE is used to calculate the cache size, as the cache size is specified as a number of pages.

### Enabling Extensions

The Berkeley DB SQL API provides extensions such as full text search and R-Tree index. By default, these two extensions are disabled. To enable an extension in the Berkeley DB SQL interface, specify the related option as an argument to the configure script using the standard environment variable, CPPFLAGS.

SQLITE_ENABLE_FTS3
  Enable building the Berkeley DB full text search layer
SQLITE_ENABLE_RTREE
  Enables the Berkeley DB R-Tree layer.

See the SQLite Documentation for more information on full text search and R-Tree.

### Building the JDBC Driver

This section describes how to build the JDBC driver code using `autoconf`, which is the only method supported and tested by the Berkeley DB team.

To build the JDBC driver, you must have Sun Java Development Kit 1.1 or above installed.

    cd build_unix
    ../dist/configure --enable-jdbc --prefix=<install path>
    make install

You can test the build by entering the following commands from the `build_unix/jdbc` directory:

javac -classpath ./sqlite.jar test3.java
java -Djava.library.path=./.libs -classpath ./sqlite.jar:. test3

### Using the JDBC Driver

This section describes the steps to download, build, and run sample programs using the built JDBC driver.

#### Downloading JDBC Sample Code

The download link for JDBC sample code is available on the Oracle Sun Developer Network (SDN). You can identify the link by the "JDBC programming examples from all three editions (ZIP format)" text beside it.

#### Modifying Sample Code

Before running the example code, do the following:

1. Unzip the file containing the sample code to a new directory (for example, jdbc_ex).
2. Substitute `jdbc:sqlite:/<db-file-name>` for the generic JDBC URL that appears in the code. That is, put `jdbc:sqlite:/<db-file-name>` between the quotation marks in the line:

   `String url = "jdbc:mySubprotocol:myDataSource";`

   Note: The <db-file-name> can either be an absolute path name like `"/jdbc_ex_db/myDataSource"`, or a relative path-file-name like `"../jdbc_ex_db/myDataSource"`, or a file name, like `"myDataSource"`, in which the database file will be stored at the current directory.

3. Substitute `SQLite.JDBCDriver` for `myDriver.ClassName` in the line: `Class.forName("myDriver.ClassName");`
4. Substitute the username and password you use for your database in the following: `"myLogin", "myPassword"`.

   This is optional.

5. If your JDK version is above 1.5, change the variable name `enum` in `OutputApplet.java` to some other variable name because, as of JDK release 5 `enum` is a keyword and can not be used as an identifier.

#### Building and Running the JDBC Sample code

See Building the JDBC Driver for instructions about building JDBC driver.

To build and run the JDBC examples do the following:

1. Copy `build_unix/jdbc/sqlite.jar` and `build_unix/jdbc/.libs/libsqlite_jni.so` to the `jdbc_ex` directory.
2. In the `jdbc_ex` directory, run the following commands:

           $ javac -classpath ./sqlite.jar *.java
           $ java -classpath .:sqlite.jar -Djava.library.path=. \
           <ClassName, eg. CreateCoffees>

3. After you run the CreateCoffees example, use the `dbsql` executable to open the `myDataSource` database file and check if the table `COFFEES` has been successfully created in the database.

           $ dbsql myDataSourcedbsql> .tables
           COFFEES
           dbsql> .dump
           PRAGMA foreign_keys=OFF;
           BEGIN TRANSACTION;
           CREATE TABLE COFFEES (COF_NAME varchar(32),\
           SUP_ID int, PRICE float, SALES int, TOTAL int);
           COMMIT;
           dbsql>

4. Repeat step 3 to run other examples.

   Note: Some examples like AutoGenKeys are not yet supported by BDB JDBC driver. The `SQLFeatureNotSupportedException` is displayed for those unsupported examples.

### Building the ODBC Driver

This section describes the steps required to build the ODBC driver.

#### Configuring Your System

To configure your system prior to building the ODBC driver, do the following:

1. Download and install the latest unixODBC if ODBC is not already installed on your system.
2. Configure the ODBC server to work with SQLite databases. Follow these instructions from Christian Werner.

#### Building the Library

To build the library, do the following

    $ cd db-5.1.XX/build_unix
    $ CFLAGS="-fPIC" ../dist/configure --enable-sql_compat --disable-shared
    $ make
    $ cd ..lang/sql/odbc
    $ CFLAGS="-DHAVE_ERRNO_H -I../../../build_unix -I../../../src/dbinc \
             -I../sqlite/src" LDFLAGS="../../../build_unix/libdb-5.1.a" \
             ./configure --with-sqlite3=../generated
    $ make

The `libsqlite3odbc.so` library containing a statically linked version of Berkeley DB SQL is now built.

NOTE: The final `make` command above is known to generate a warning when using GCC. The warning states: `Warning: Linking the shared library libsqlite3odbc.la against the static library ../../build_unix/libdb-5.1.a is not portable!`. It is generally safe to ignore the warning when using the generated library.

#### Testing the ODBC Driver

The steps to verify that the installed driver works are as follows:

1. Alter the `/etc/odbcinst.ini` and `~/.odbc.ini` configuration files to refer to the libsqlite3odbc.so file built above.

2. Create a data source, and launch a data source viewer application by doing the following:

       $ mkdir ~/databases
       $ cd ~/databases
       $ /path/to/Berkeley DB/build_unix/sqlite3 mytest.db
       dbsql> CREATE TABLE t1(x);
       dbsql> .quit;
       $ DataManager

   The final step opens a GUI application that displays ODBC data sources on a system. You should be able to find the `mytest.db` data source just created.

Prev | Up | Next
Configuring Berkeley DB | Home | Building a small memory footprint library