If a database model does not produce the expected results right away, it can be tricky to figure out what is going wrong. The cause can lie with the application, with the specified properties, with the database, etc. Luckily, there are a number of ways to debug what is going on, at different levels in the application.

LuciadLightspeed

Like any other model decoder, LuciadLightspeed will produce an IOException if it fails to open a spatial database model. The message of the IOException should provide more details on the origin of the problem. Typically, some properties are not set correctly, or the spatial database is not set up properly.

In addition, you can get feedback on the SQL queries that are sent to the database, by switching on logging for the relevant package. See the Logging documentation for more information on setting up logging in a LuciadLightspeed application.

The initial queries that you will see in the logging output generally request some metadata about the spatial tables. Subsequent queries will typically request the actual data, based on spatial bounds and on primary keys. If one of the queries fails, you can try to copy/paste it in an interactive SQL console, to see which part is causing problems. This can be especially useful if you have specified additional selection tables and filters, which are weaved into the SQL query.

JDBC

At a lower level, you can get feedback about any JDBC operations, directly from JDBC. The JDBC API provides a standard hook, which you can set up from your program by calling:

DriverManager.setLogWriter(new PrintWriter(System.out));

Oracle JDBC driver

At similarly low level, the Oracle driver can provide feedback about its interactions with the Oracle database. The Oracle driver provides a debug flag that you can specify from the command line. For this flag to work, the debugging jar ojdbc_g.jar has to be specified in the class path instead of the traditional jar ojdbc.jar. The java command line then looks something like:

java -Doracle.jdbc.Trace=true -Djava.util.logging.config.file=OracleLog.properties ......

Optionally, the resulting output can be directed to a file instead of to the console, with -Doracle.jdbc.LogFile=/tmp/jdbc.log. More details about debugging with the help of the Oracle driver can be found at

Proxool driver

If you are implementing connection pooling with the help of the Proxool driver, you can also activate its logging. Proxool uses the Apache Commons logging facilities, which is an abstraction on top of a number of logging libraries. For example, one of these is the log4j library. It can be configured by creating a log4j.properties file, like the one in Program: A sample log4j.properties configuration file., which has to be put in the class path.

Program: A sample log4j.properties configuration file.
log4j.rootLogger=DEBUG, myappender
log4j.appender.myappender=org.apache.log4j.ConsoleAppender
log4j.appender.myappender.layout=org.apache.log4j.PatternLayout
log4j.appender.myappender.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

log4j.logger.org.logicalcobwebs.proxool=TRACE

Logging is then activated by starting the application with the configuration file and the necessary library jars in the class path:

java -cp commons-logging.jar:log4j.jar ......

More information on Apache Commons logging and log4j can be found at

and