Free jdbc 2.0 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.

Need a Type 3 JDBC Driver for MS Access or SQL Server? Think RmiJdbc!
RmiJdbc project is a client/server JDBC Driver that relies on Java RMI.
All JDBC classes (like Connection, ResultSet, etc...) are distributed as RMI objects, so that you can distribute as you like the access to any database supporting the JDBC API.
In fact, RmiJdbc is just a bridge to allow remote access to JDBC drivers.
Why RmiJdbc?
- You develop a client/server application with databases on Windows (NT)? Use RmiJdbc along with the JDBC/ODBC Bridge, your Windows (NT) databases become remotely accessible in Java.
- You implement a JDBC Driver? Just implement the JDBC classes locally, dont bother with remote access!
- You need serializable JDBC classes? Here they are.
Enhancements:
- Add features/limitations/changes here

HDBC is a Haskell Database Connectivity.

HDBC provides an abstraction layer between Haskell programs and SQL relational databases. This lets you write database code once, in Haskell, and have it work with any number of backend SQL databases (MySQL, Oracle, PostgreSQL, ODBC-compliant databases, etc.)

HDBC is modeled loosely on Perls DBI interface http://search.cpan.org/~timb/DBI/DBI.pm, though it has also been influenced by Pythons DB-API v2, JDBC in Java, and HSQL in Haskell.

HDBC is a from-scratch effort. It is not a reimplementation of HSQL, though its purpose is the same.

Jaybird is JCA/JDBC driver suite to connect to Firebird database server. Historically Borland opened sources of type 3 JDBC driver called InterClient.

However due to some inherent limitations of Firebird client library it was decided that type 3 driver is a dead end, and Firebird team developed pure Java implementation of wire protocol.

This implementation became basis for JayBird, pure Java driver for Firebird relational database.

This driver is based on both the new JCA standard for application server connections to enterprise information systems and the well known JDBC standard.

The JCA standard specifies an architecture in which an application server can cooperate with a driver so that the application server manages transactions, security, and resource pooling, and the driver supplies only the connection functionality.

While similar to the JDBC 2 XADataSource idea, the JCA specification is considerably clearer on the division of responsibility between the application server and driver.

JayBird 1.5 provides extensions to some JDBC interfaces. All extension interfaces are released under modified BSD license, on “AS IS” basis, this should make linking to these classes safe from the legal point of view. All classes belong to org.firebirdsql.jdbc.* package.

JayBird 1.0 provided only pure Java wire protocol implementation. While being most effective in client-server setups (even more effective than native client libraries), it performed worser when connected to the server residing on the same host compared to native (C/C++/Delphi/etc) solutions. Reason is that type 4 driver communicates with the server using network sockets, which introduce additional overhead. Native client library has possibility to use IPC when connecting to the database on the same host. This might increase performance even by 100%.

JayBird 1.5 provides also type 2 JDBC driver that uses native client library to connect to the databases. Additionally JayBird 1.5 can use embedded version of Firebird relational database allowing to create Java applications that does not require separate server setup.

However type 2 driver has also limitations. Due to multi-threading issues in Firebird client library, it is not possible to access it from different threads simultaneously when running in local mode (IPC). In this case only one thread is allowed to access library at a time. Driver tries to provide needed synchronization.

Current implementation uses mutex that is local to the classloader that loaded JayBird classes. This poses some deployment limitations: firebirdsql.jar must be deployed so, that it is loaded by the system classloader. For standalone web containers like Resin or Tomcat, JayBird should usually be deployed in their lib/ directory. It is allowed to include it in the WAR archives, but if and only if it is guaranteed that only one application will access Firebird.

When accessing remote servers thread per connection policy applies. Driver provides necessary synchronization for this situation.

Embedded version of the server cannot be used on Linux systems in multi-threaded applications. In particular this makes embedded version of the server unusable for web applications, where usually each request is served in separate thread.

Hydrate is a Java tool that provides for fast efficient and error-free transformation of data between three different representations: relational databases, objects in an object-oriented programming language and extended markup language (XML).
Each of these representations has its strengths and weaknesses as shown in the diagram below; but which should you use as a basis for your application design?
Hydrate relaxes some of the pressure on this decision by providing tools for moving data from one representation to another, guided by a master UML class representation of that data.
- You want to lay a domain object model view over an existing database or set of databases. Hydrate gives you the tools to design that model in UML and map your existing data to that model. Once in the object space, you can perform complex manipulations on the objects, calculate results and save information back to a relational cache for searching or reloading, as well as converting the results to XML for sending to downstream systems or transforming to a readable format for display.
- Your project involves taking various data files fed from external systems that you want to pull into an object model on your server before writing the results down to a fully relational database. You can now respond to requests from external systems by rehydrating the data from its relational form and sending it out as XML documents or transforming those documents to a readable format for display.
- You are building a data warehouse in which you have the broad specifications for the model, but want to provide for flexibility and adaptability for future unpredicted requests. Based on a core data model, Hydrate gives you the tools to create you database schema, and write information to it, but more significantly to subsequently lay a completely different object model perhaps aggregating some of the data over the top of that schema to process it in unforeseen ways.
- You need to integrate data from many different data sources in a highly performant manner. SQL permits you to read a huge data set a row at a time and perform running calculations and filtering on that data. But the performance pressures can lead to code that is highly coupled with the database and what do you do if you need to integrate data from elsewhere in order to complete your calculations? Hydrate permits you to operate in the object space and integrate information from other sources on-the-fly.
Main features:
- To integrate legacy and other data schemas over which you have little control. Map data from many different data sources into a single self-consistent in-memory model. Different parts of the same object, as well as different sub-populations of the same object type can be drawn from different data sources, different schemas and even different database architectures.
- Load, populate and connect up multiple object types from a single query. There is no limit to the number of object types that can be loaded from a single query, or to the complexity of the relationships that can be resolved between them. Objects read from a query are automatically merged into objects already in memory.
- Full control over the SQL that runs against the database (if you need it). Any SQL queries simultaneously from multiple JDBC drivers, even using database specific optimizations, as long as they returns a result set.
- Access and manipulate the same data through the rich and powerful XML toolset. Use the same meta data that describes your objects to easily read from, write to and validate any consistent XML schema. Use XML for display, data transmission or XSLT transformation. Load XML data back into objects.
- Highly optimized performance for reading and writing SQL and XML. Since native types are used and SQL chatter is non-existent, database performance is comparable with doing the mapping by hand. XML reading and writing uses SAX exclusively.

db2dot reverse engineers an existing database and produces an ER diagram in dot format.

The dot file can be fed through graphvizs dot to produce a pretty ER diagram. The diagram includes tables and relationships derived from db meta-data and foreign key constraints.

What format is the output?

It generates a dot file which can be turned into a diagram with the graphviz utility.

What database servers will it work with?

It has only been tested with MySQLs JDBC driver, but it uses only
generic java.sql.* classes so it should work with any JDBC driver which is
sufficiently advanced.

What license is the code released under?

db2dot is released under the GPL v2.0 license.

How do I build the source?

Run: ant build jar

What are the command line arguments?

The command line arguments may be in any order, the following are required:

driver=< JDBCDriver class >
url=< db connection url >
user=< db user name >
pass=< db password >

The following are optional:

+showRelations
+showColumns

picoSQL project is the first Italian Open Source relational database management system.
The project of picoSQL was born in 1995. It was an ODBC driver for COBOL indexed files. It consisted of a DLL written in C++ on Windows 3.1 operating system. In the beginning the main effort was made in order to obtain a good compatibity with existing front-end (mainly the MS-Access, MS-Query and VisualBasic) and in order to see COBOL files as a normalized relational DB.
The obtained success concurs to develop ulteriorly the product, refining the query optimizer and implementing an extended SQL, to exclusion of the DDL (Data Description Language). A later version, called PicoDB, were devoloped on UNIX system in client/server architecture.
PicoSql is released under GPL license; it derives from PicoDB (that remains a Picosoft proprietary product) with the addition of some SQL-DDL statement (CREATE/DROP TABLE(INDEX) and excluding COBOL files compatibility). The C/C++ library that allow the database access from C/C++ programs using the ODBC 2.5 API is released under LGPL license; this allows to link the library with programs that are not under GPL.
PicoSQL can be used from Windows applications (like MS-ACCESS, MS-Query, VB etc.) in client/server modality using the ODBC driver picoSQLNet. It can moreover be used from appropriate Java programs through the JDBC driver comprised in the distribution. Finally it can be used from programs written in C and C++ through its set of ODBC 2.5 compliant API.
PicoSQL lacks at the moment of some common characteristics to the most common RDBMS (like the schema and catalogue concepts and the management of the user permissions who can be obtained anyway using the permissions of the host operating system) but they are just these lacks to make it particularly simple to install and to use and fast in the logons and the queries.
Installation:
The installation is particularly simple: if you have the binary distribution, is sufficient to extract the compressed files in one directory ( under Windows NT/2000/XP) and execute:
startTestDb.sh (Unix/Linux)
PicoSQL consists fundamentally in a program, picosqld, to activate through inetd (or xinetd) or picoserv. In such a way it becomes a net service binded to a port, that is to a entire number comprised between 1 and 65535; this number (as an example 6789) must always be specified on the command line of picosqld. As an example:
picosqld 6789
For the activation with inetd (or xinetd), you must see the relative documentation. picoserv is a simple program that replaces inetd, mainly for scopes of test or debugging: its usage is the following:
picoserv [-f] commandLine portNumber
In our case the activation of picosqld can be obtained with the following command line:
picoserv "picosqld 6789" 6789
To notice as the port number is specified two times, as an argument of picosqld and as an argument of picoserv.
When picosqld receive a connection request, it reads a configuration file to find the necessary informations. This file is a text file on Unix/Linux systems.
# Unix/Lunixthe file read for configuration is
$HOME/.picosql.ini
or, if this file is missing
/etc/picosql.ini
The file consists of sections and parameters. A section begins with the name of the section in square brackets and continues until the next section begins. Sections contain attributes of the form
name=value
The file is line-based - that is, each newline-terminated line represents either a comment, a section name or a parameter. Section and parameter names are not case sensitive. Only the first equals sign in a parameter is significant. Any line beginning with a semicolon (;) or a hash (#) character is ignored, as are lines containing only whitespace. Each section corresponds to a database and comprises information like user, password and DB location. In the following example there are two database declared, the former called picoSqlTest, is accessible by anyone while the latter, called rubrica is accessible only by user pico giving the appropriate password.
[picoSqlTest]
DataDirectory=/home/test.db
[rubrica]
DataDirectory=/home/rubrica.db
User=pico
Password=soft
PicoOdbcTrace=NO
SuspensiveLock=YES
; for picosql client only
server=localhost
port=6789
Enhancements:
- This version fixes a problem on authentication and a bug when the connection fails.