Free jdbc odbc software for linux

JDBC is a Perl 5 interface to Java JDBC (via Inline::Java).

SYNOPSIS

use JDBC;

JDBC->load_driver("org.apache.derby.jdbc.EmbeddedDriver");

my $con = JDBC->getConnection($url, "test", "test");

my $s = $con->createStatement();

$s->executeUpdate("create table foo (foo int, bar varchar(200), primary key (foo))");
$s->executeUpdate("insert into foo (foo, bar) values (42,notthis)");
$s->executeUpdate("insert into foo (foo, bar) values (43,notthat)");

my $rs = $s->executeQuery("select foo, bar from foo");
while ($rs->next) {
my $foo = $rs->getInt(1);
my $bar = $rs->getString(2);
print "row: foo=$foo, bar=$barn";
}

This JDBC module provides an interface to the Java java.sql.* and javax.sql.* JDBC APIs.

DBD::ODBC Perl module contains a ODBC Driver for DBI.

SYNOPSIS

use DBI;

$dbh = DBI->connect(dbi:ODBC:DSN, user, password);

Private DBD::ODBC Attributes

odbc_more_results (applies to statement handle only!)
Use this attribute to determine if there are more result sets available. SQL Server supports this feature. Use this as follows:

do { my @row; while (@row = $sth->fetchrow_array()) { # do stuff here } } while ($sth->{odbc_more_results});

Note that with multiple result sets and output parameters (i.e. using bind_param_inout, dont expect output parameters to be bound until ALL result sets have been retrieved.
odbc_ignore_named_placeholders

Use this if you have special needs (such as Oracle triggers, etc) where :new or :name mean something special and are not just place holder names You must then use ? for binding parameters. Example: $dbh->{odbc_ignore_named_placeholders} = 1; $dbh->do("create trigger foo as if :new.x :old.x then ... etc");

Without this, DBD::ODBC will think :new and :old are placeholders for binding and get confused.

odbc_default_bind_type

This value defaults to 0. Older versions of DBD::ODBC assumed that the binding type was 12 (SQL_VARCHAR). Newer versions default to 0, which means that DBD::ODBC will attempt to query the driver via SQLDescribeParam to determine the correct type. If the driver doesnt support SQLDescribeParam, then DBD::ODBC falls back to using SQL_VARCHAR as the default, unless overridden by bind_param()

odbc_force_rebind

This is to handle special cases, especially when using multiple result sets. Set this before execute to "force" DBD::ODBC to re-obtain the result sets number of columns and column types for each execute. Especially useful for calling stored procedures which may return different result sets each execute. The only performance penalty is during execute(), but I didnt want to incur that penalty for all circumstances. It is probably fairly rare that this occurs. This attribute will be automatically set when multiple result sets are triggered. Most people shouldnt have to worry about this.

odbc_async_exec

Allow asynchronous execution of queries. Right now, this causes a spin-loop (with a small "sleep") until the SQL is complete. This is useful, however, if you want the error handling and asynchronous messages (see the err_handler) below. See t/20SQLServer.t for an example of this.

odbc_exec_direct

Force DBD::ODBC to use SQLExecDirect instead of SQLPrepare() then SQLExecute. There are drivers that only support SQLExecDirect and the DBD::ODBC do() override doesnt allow returning result sets. Therefore, the way to do this now is to set the attributed odbc_exec_direct. There are currently two ways to get this: $dbh->prepare($sql, { odbc_exec_direct => 1}); and $dbh->{odbc_exec_direct} = 1; When $dbh->prepare() is called with the attribute "ExecDirect" set to a non-zero value dbd_st_prepare do NOT call SQLPrepare, but set the sth flag odbc_exec_direct to 1.

odbc_err_handler

Allow errors to be handled by the application. A call-back function supplied by the application to handle or ignore messages. If the error handler returns 0, the error is ignored, otherwise the error is passed through the normal DBI error handling structure(s).

This can also be used for procedures under MS SQL Server (Sybase too, probably) to obtain messages from system procedures such as DBCC. Check t/20SQLServer.t and mytest/testerrhandler.pl

The callback function takes three parameters: the SQLState, the ErrorMessage and the native server error.

odbc_SQL_ROWSET_SIZE

Here is the information from the original patch, however, Ive learned since from other sources that this could/has caused SQL Server to "lock up". Please use at your own risk!
SQL_ROWSET_SIZE attribute patch from Andrew Brown > There are only 2 additional lines allowing for the setting of > SQL_ROWSET_SIZE as db handle option. > > The purpose to my madness is simple. SqlServer (7 anyway) by default > supports only one select statement at once (using std ODBC cursors). > According to the SqlServer documentation you can alter the default setting > of > three values to force the use of server cursors - in which case multiple > selects are possible. > > The code change allows for: > $dbh->{SQL_ROWSET_SIZE} = 2; # Any value > 1 > > For this very purpose. > > The setting of SQL_ROWSET_SIZE only affects the extended fetch command as > far as I can work out and thus setting this option shouldnt affect > DBD::ODBC operations directly in any way. > > Andrew >

SQL_DRIVER_ODBC_VER

This, while available via get_info() is captured here. I may get rid of this as I only used it for debugging purposes.
odbc_cursortype (applies to connect only!)

This allows multiple concurrent statements on SQL*Server. In your connect, add { odbc_cursortype => 2 }. If you are using DBI > 1.41, you should also be able to use { odbc_cursortype => DBI::SQL_CURSOR_DYNAMIC } instead. For example:

my $dbh = DBI->connect("dbi:ODBC:$DSN", $user, $pass, { RaiseError => 1, odbc_cursortype => 2});
my $sth = $dbh->prepare("one statement");
my $sth2 = $dbh->prepare("two statement");
$sth->execute;
my @row;
while (@row = $sth->fetchrow_array) {
$sth2->execute($row[0]);
}

See t/20SqlServer.t for an example.

odbc_query_timeout

This allows the end user to set a timeout for queries on the ODBC side. After your connect, add { odbc_query_timeout => 30 } or set on the dbh before executing the statement. The default is 0, no timeout. Note that some drivers may not support this attribute.

See t/20SqlServer.t for an example.

odbc_has_unicode (applies to database handle only)
A read-only attribute signifying whether DBD::ODBC was built with the C macro WITH_UNICODE or not. A value of 1 indicates DBD::ODBC was built with WITH_UNICODE else the value returned is 0.

Building WITH_UNICODE affects columns and parameters which are SQL_C_WCHAR, SQL_WCHAR, SQL_WVARCHAR, and SQL_WLONGVARCHAR.

When odbc_has_unicode is 1, DBD::ODBC will:

bind columns the database declares as wide characters as SQL_Wxxx

This means that UNICODE data stored in these columns will be returned to Perl in UTF-8 and with the UTF8 flag set.
bind parameters the database declares as wide characters as SQL_Wxxx

Parameters bound where the database declares the parameter as being a wide character (or where the parameter type is explicitly set to a wide type - SQL_Wxxx) can be UTF8 in Perl and will be mapped to UTF16 before passing to the driver.
NOTE: You will need at least Perl 5.8.1 to use UNICODE with DBD::ODBC.

NOTE: At this time SQL statements are still treated as native encoding i.e. DBD::ODBC does not call SQLPrepareW with UNICODE strings. If you need a unicode constant in an SQL statement, you have to pass it as parameter or use SQL functions to convert your constant from native encoding to Unicode.

NOTE: Binding of unicode output parameters is coded but untested.

NOTE: When building DBD::ODBC on Windows ($^O eq MSWin32) the WITH_UNICODE macro is automatically added. To disable specify -nou as an argument to Makefile.PL (e.g. nmake Makefile.PL -nou). On non-Windows platforms the WITH_UNICODE macro is not enabled by default and to enable you need to specify the -u argument to Makefile.PL. Please bare in mind that some ODBC drivers do not support SQL_Wxxx columns or parameters.

UNICODE support in ODBC Drivers differs considerably. Please read the README.unicode file for further details.

odbc_version (applies to connect only!)

This was added prior to the move to ODBC 3.x to allow the caller to "force" ODBC 3.0 compatibility. Its probably not as useful now, but it allowed get_info and get_type_info to return correct/updated information that ODBC 2.x didnt permit/provide. Since DBD::ODBC is now 3.x, this can be used to force 2.x behavior via something like: my $dbh = DBI->connect("dbi:ODBC:$DSN", $user, $pass, { odbc_version => 2});

HA-JDBC project is a JDBC driver implementation that provides light-weight, transparent clustering capabilities to groups of homogeneous JDBC- accessed databases.
Main features:
- Supports any database accessible via JDBC.
- High-availability - Database cluster can lose a node without failing the current transaction.
- Improves performance of concurrent read-access by distributing load across individual nodes.
- Support for full JDBC 3.0 (Java 1.4) feature set.
- Compatible with JDBC RowSet implementations found in Java 1.5.
- Out-of-the-box database-independent strategies for synchronizing a failed cluster node.
- Exposes JMX management interface to allow administration of database clusters.
- Open source (LGPL).

JdbcTool project is a collection of command line utilities for making your life easy when working with Java JDBC databases. Included are:

jdbctool:

An interactive command line tool for executing SQL statements.

jdbcdump:

Dump the contents of a database as SQL statements into a file, like mysqldump.

jdbcload

Execute SQL statements from a file (the opposite of jdbcdump)

Currently, only HSQLDB is supported.

SQLiteJDBC is a JDBC driver for SQLite which is written as a Java JNI layer over the SQLite 3.3.x API.

SQLiteJDBC supports the most commonly used features of JDBC that can be efficiently implemented on top of SQLite. Only a single native JNI library is required, and SQLite is compiled in.

Binaries are provided for Linux, Mac OS X, and Windows.

JDBCImporter provides a consistent mechanism for importing data from a file to a database, exporting data from a database to a file, and generating data.
JDBCImporter API can run from the command line using an XML config file or from inside an Ant build script. It works with CSV, fixed data, and XML files and supports numbers, strings, and date/times as database column types.
Custom classes can be used to parse different file formats, format column values into different file formats, translate column values before importing or after exporting, or allocate or release JDBC connections.
Installation:
Below are the installation steps for installing JDBC Importer:
unzip the jdbcimporter.zip file
add jdbcimporter.jar and commons-logging.jar to the CLASSPATH.
For example: set CLASSPATH=%CLASSPATH%;INSTALL_DIRlibjdbcimporter.jar;INSTALL_DIRlibcommons-logging.jar
JDBC Importer
Basic Usage:
> java [options] net.sourceforge.jdbcimporter.Importer [plugin file]
where :
config file : the import config file
plugin file : the (optional) property file that describes the plugins available during the import
options : two system properties may be set (both are optional)
jdbcimporter.engine = The import engine to use
jdbcimporter.failonerror = Flag indicating that the import should end if an error occurrs
Enhancements:
- This release fixes a bug with CSV delimiter parser.

DBD::ODBC::Changes is a Perl module with logs of significant changes to the DBD::ODBC.

jTDS is an open source 100% pure Java (type 4) JDBC 3.0 driver for Microsoft SQL Server (6.5, 7, 2000 and 2005) and Sybase (10, 11, 12, 15). jTDS is based on FreeTDS and is currently the fastest production-ready JDBC driver for SQL Server and Sybase.
jTDS is 100% JDBC 3.0 compatible, supporting forward-only and scrollable/updateable ResultSets, concurrent (completely independent) Statements and implementing all the DatabaseMetaData and ResultSetMetaData methods.
Quite a few of the commercial JDBC drivers out there are based on jTDS (or FreeTDS), even if they no longer acknowledge this.
jTDS has been tested with virtually all JDBC-based database management tools and is the driver of choice for most of these (recommended for DbVisualizer and SQuirreL SQL, distributed with Aqua Data Studio and DataDino).
jTDS is also becoming a common choice for enterprise-level applications: it passes both the J2EE 1.3 certification and Hibernate test suites, and is recommended for JBoss, Hibernate, Atlassian JIRA and Confluence and Compiere.
jTDS is free software. jTDS is released under the terms of the GNU LGPL, giving you not only the posibility to debug and tweak it to your own liking but also to use it in and distribute it with your free or commercial applications.
The other "free" choices, the JDBC-ODBC bridge and Microsofts own JDBC driver are not actually free. If you encounter an issue with any of them you wont be able to fix it yourself and response times from both Microsoft and Sun are anything but short. Also, both of them lack functionality (the Microsoft driver implements JDBC 2.0, while the bridge is just a JDBC 1.0 implementation) and have serious stability problems: the bridge crashes the JVM if the ODBC driver has any problem and Microsoft just has no intention of really supporting Java/JDBC.
jTDS is also the most performant JDBC driver for both SQL Server and Sybase. We have an older benchmark result but we strongly encourage you to download any benchmark published by commercial JDBC driver vendors and see for yourself. Here are a couple of benchmarks you could use: JNetDirects JDBC Performance Benchmark and i-net Softwares BenchTest 2.1 for MS SQL Server.
Anyway, just give it a spin.
Enhancements:
New features:
- Support for Sybase ASE 15
- Improved support for SQL Server 2005 varchar(max) and varbinary(max)
- Complete handling of cursor exceptions and downgrading
- Better handling of cancels and timeouts
- Configurable socket timeout
- Subclasses of basic JDBC types recognized as setObject() values
Major bug fixes (out of over 30 fixes):
- Statement pool memory leak
- Java 1.5 BigDecimal problems
- Possible synchronization problems
- setAutoCommit() behavior not according to specification
- getTimestamp() returns invalid value after calling getString()
- Cursor opens fails when cursor threshold -1
- iso_1 charset and Sybase
- "All pipe instances are busy" not handled properly
- SSL fails with SQL Server 2005
- Sybase: insert UTF8 string fails when length is 255