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:
Note that while this option is meant for use with the SQL interface, it will also disable checksum for the non-SQL interfaces.
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.
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-sql or
--enable-sql_compat to build
the SQLite Tcl test runner.
Causes the JDBC driver to be built. Setting
this option implies that
--enable-sql is set, which
means that the Berkeley DB SQL API will be built
too.
Enables encryption support for the Berkeley DB SQL interface. See SQL Encryption in the Berkeley DB Getting Started with the SQL APIs guide for usage details.
The following configuration options are useful when debugging applications:
Any arguments that you can provide to the standard SQLite configure script can also be supplied when configuring Berkeley DB SQL interface.
There are several configuration options you can specify as an argument to the configure script using the standard environment variable, CFLAGS. For example, to configure with the option BDBSQL_FILE_PER_TABLE, do the following:
$ ../dist/configure --enable-sql CFLAGS="-DBDBSQL_FILE_PER_TABLE=1"
metadata and
table00001 files from the
database directory. Make a new copy whenever the
schema is changed.
The Berkeley DB SQL API provides extensions such as full text search, R-Tree index, user authentication and key-store based user authentication. By default, these 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.
See the SQLite Documentation for more information on Full Text Search and R-Tree.
For more information on user authentication and key-store based user authentication, see Berkeley DB Getting Started with the SQL APIs.
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 |
This section describes how to download, build, and run sample programs using the built JDBC driver.
The download link for JDBC sample code is available on the Oracle Technology Network (OTN) page. You can identify the link by the "JDBC programming examples from all three editions (ZIP format)" text beside it.
Before running the example code, do the following:
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:sqlite://jdbc_ex_db/myDataSource",
or a relative path-file-name like
"jdbc:sqlite:/../jdbc_ex_db/myDataSource",
or a file name, like
"jdbc:sqlite:/myDataSource",
in which case the database file will be stored
at the current directory. Note that all path
arguments require a leading slash, even in the
case of relative paths or a database in the
local directory. Please refer to the above
examples.
SQLite.JDBCDriver for
myDriver.ClassName in the
line:
Class.forName("myDriver.ClassName");
Optionally substitute the username and
password you use for your database in the
following: "myLogin",
"myPassword".
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.
See Building the JDBC Driver for instructions on building the JDBC driver.
To build and run the JDBC examples do the following:
build_unix/jdbc/sqlite.jar
and
build_unix/jdbc/.libs/libsqlite_jni.so
to the jdbc_ex directory.
In the jdbc_ex
directory, run the following commands:
$ javac -classpath ./sqlite.jar *.java
$ java -classpath .:sqlite.jar -Djava.library.path=. \
<ClassName, eg. CreateCoffees>
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>Repeat step 3 to run other examples.
Note: Some examples, such as AutoGenKeys,
are not yet supported by BDB JDBC driver. The
SQLFeatureNotSupportedException
is displayed for those unsupported examples.
This section describes how to build the ODBC driver.
To configure your system prior to building the ODBC driver, do the following:
To build the library without encryption, do the following:
$ cd db-6.2.XX/build_unix
$ CFLAGS="-fPIC" ../dist/configure --enable-sql_compat --disable-shared
$ make
$ cd ../lang/sql/odbc
$ CFLAGS="-D_HAVE_SQLITE_CONFIG_H \
-I../../../build_unix -I../../../build_unix/sql \
-I../../../src/dbinc -I../sqlite/src -I../../../src" \
LDFLAGS="../../../build_unix/libdb-6.2.a" \
./configure --with-sqlite3=../generated
$ make
To build the library with encryption, do the following:
$ cd db-6.2.XX/build_unix
$ CFLAGS="-fPIC" ../dist/configure --enable-sql_compat \
--disable-shared --with-cryptography=yes
$ make
$ cd ../lang/sql/odbc
$ CFLAGS="-D_HAVE_SQLITE_CONFIG_H -DSQLITE_HAS_CODEC=1 \
-I../../../build_unix -I../../../build_unix/sql \
-I../../../src/dbinc -I../sqlite/src" \
LDFLAGS="../../../build_unix/libdb-6.2.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-6.2.a is not
portable!. It is generally safe to
ignore the warning when using the generated library.
The steps to verify that the installed driver works are as follows:
/etc/odbcinst.ini and
~/.odbc.ini configuration
files to refer to the libsqlite3odbc.so file built
above.
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
$ odbcinst -m
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.
The BFILE extension allows you to store binary files
outside of the database, but still operate upon them as if
they were stored within the database. To enable this
extension, use the
--enable-load-extension
configuration flag. For example:
$ cd <db>/build_unix
$ export DBSQL_DIR=$PWD/../install
$ ../dist/configure --enable-sql --enable-load-extension \
--prefix=$DBSQL_DIR && make && make install
$ cd ../lang/sql/sqlite/ext/bfile/build
$ make && make install
BFILE extensions are only supported for Unix platforms.
Note that the extension support has two interfaces: SQL
expressions and a C-functions API. By default, the SQL
expressions are built when you use
--enable-load_extension. To use the
C-functions API, edit
<db>/lang/sql/ext/bfile/build/Makefile
and set ENABLE_BFILE_CAPI to
1.
Once you have enabled the extension and built the library, you can run the included example:
$ cd lang/sql/sqlite/ext/bfile/build $ export LD_LIBRARY_PATH=$PWD:$DBSQL_DIR/lib $ ./bfile_example_sql # for SQL expressions interface $ ./bfile_example_capi # for C-functions API
For more information on using the BFILE extension, see the Berkeley DB Getting Started with the SQL APIs guide.