Free dbd jdbc 0.70 software for linux

DBD::JDBC is a JDBC proxy driver for the DBI module.

SYNOPSIS

use DBI;

$dbh = DBI->connect("dbi:JDBC:hostname=$hostname;port=$port;url=$url",
$user, $password);

# See the DBI module documentation.

DBD::JDBC is a Perl module which works in conjunction with a server written in Java to provide a DBI front end to a JDBC driver. The Perl module and Java server may be installed on different machines, as long as socket connections are allowed. The Java server portion is multi-threaded and supports multiple simultaneous connections.

This driver currently supports JDBC drivers which implement the JDBC 1.22 interface. JDBC 2.0-compatible drivers are expected to work, but no JDBC 2.0 functionality is explicitly exposed via DBD::JDBC. The $h->jdbc_func method exposes additional JDBC and driver-specific methods. Only Java methods with primitive or String parameters and return types are currently supported in this way.

The expected use for this module is as a DBI interface to databases with JDBC drivers but no DBI drivers. The implementation of this module was originally done for a non-SQL database in order to take advantage of the existing SQL parser in the databases JDBC driver.

The Java classes provided with this module also allow a Java application or servlet to create a JDBC connection and then execute a Perl script which can use that pre-existing JDBC connection via DBI. This particular functionality was implemented in order to allow Perl customizations to a Java servlet-based application. See the example in the example/ directory.

DBD-DB2 is a DB2 Driver for DBI.

BUILDING:

On UNIX:

perl Makefile.PL # use a perl thats in your PATH make
make test
make install (if the tests look okay)

On Windows:

perl Makefile.PL
nmake
nmake test
nmake install

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});

rdiald is an application which allows users from a local network to initiate dialup connections.
rdiald allows users in your home network to initiate a dialup connection to one of a freely configurable set of internet service providers on the server rdiald is running on. Multiple users can be online at the same time, and the connection is only terminated once the last user goes offline.
The users are allowed to execute any commands that have been defined previously on the server and to hang up as soon as these commands have finished.
Enhancements:
- improved handling of mulitple clients, especially during
- hang-up phase
- -i command-line option to bind to a specific interface only
- detection of a newly established dialup-link has changed:
- now a script that is started from ip-up is telling rdiald that the link is up, allowing a finer level of control as to when the link availability is broadcast to clients

When reading a lot of data from disk or network filesystem, e.g. during a backup, buffer cache pollution can be a substantial performance problem for other processes on the machines involved due to buffer cache pollution. odirect is intended to provide a convenient way of avoiding that on systems that offer an O_DIRECT value for open().
odirect provides a C library and SWIG code to make it easy to use from your favorite scripting language.
This project is in the toddler stage:
tests run:
- Ive tested the C library from a C program. This test only reads via odirect
- Ive tested the swig interface code via a python script that uses the swig interface directly. This test too only reads via odirect
- Ive tested the swig interface code via a python wrapper that gives module much more pythonic functionality. This test reads via both odirect and the usual Python file I/O, and compares
- Ive tested the pythonic interface wrapped with bufsock. This test only reads via odirect, but bufsock adds the ability to read sub-block pieces from a buffered full-length block
Caveats:
- Although the tests are pretty good, Ive used this in only one real application so far - and thats my pyindex program
- Ive only tested with C and Python so far, and frankly, Im pretty happy leaving it there for now at least, since my favorite programming languages at this time are C, bash and Python. If youre interested in other languages, please drop me a note - ideal would be diffs for the Makefile and any supporting files, like odirect.whateverExtension wrappers.
- 0.55 had no write support; only read. The current version, 0.65, has 100% untested write support. Thats right - all that testing is only checking reading.
- No "install" rule in the Makefile yet.
- The various python modules insert "." on their python path from too many places; this should be done in the test programs themselves, not the module(s) lest we create (and leave) a security issue
Enhancements:
- This release adds C++ support, bringing the list of supported languages to C, C++, and Python.

DBD::AnyData is a DBI access to XML, CSV and other formats.

SYNOPSIS

use DBI;
my $dbh = DBI->connect(dbi:AnyData(RaiseError=>1):);
$dbh->func( trains, CSV, /users/joe/cars.csv, ad_catalog);
$dbh->func( bikes, XML, [$xml_str], ad_import);
$dbh->func( cars, DBI, $mysql_dbh, ad_import);
#
# ... DBI/SQL methods to access/modify the tables cars,bikes,trains
#
print $dbh->func( cars, HTMLtable, ad_export);

or

use DBI;
my $dbh = DBI->connect(dbi:AnyData(RaiseError=>1):);
$dbh->func( Pipe, data.pipe, XML, data.xml, ad_convert);

or

(many combinations of a dozen other data formats, see below)

The DBD::AnyData module provides a DBI/SQL interface to data in many formats and from many sources.

Currently supported formats include general format flatfiles (CSV, Fixed Length, Tab or Pipe "delimited", etc.), specific formats (passwd files, web logs, etc.), a variety of other kinds of formats (XML, Mp3, HTML tables), and, for some operations, any DBI accessible database. The number of supported formats will continue to grow rapidly since there is an open API making it easy for any author to create additional format parsers which can be plugged in to AnyData.

Data in these various formats can come from local files, from remote files, or from perl data structures such as strings and arrays.

Regardless of the format or source of the data, it may be accessed and/or modified using all standard DBI methods and a subset of SQL syntax.

In addition to standard database access to files, the module also supports in-memory tables which allow you to create temporary views; to combine data from a number of sources; to quickly prototype database systems; and to display or save the data in any of the supported formats (e.g. to display data in a CSV file as an HTML table).

These in-memory tables can be created from any combination of DBI databases or files of any format. They may also be created from perl data structures which means its possible to quickly prototype a database system without any file access or rdbms backend.

DBM::Deep is a pure perl multi-level hash/array DBM.

SYNOPSIS

use DBM::Deep;
my $db = DBM::Deep->new( "foo.db" );

$db->{key} = value; # tie() style
print $db->{key};

$db->put(key => value); # OO style
print $db->get(key);

# true multi-level support
$db->{my_complex} = [
hello, { perl => rules },
42, 99,
];

A unique flat-file database module, written in pure perl. True multi-level hash/array support (unlike MLDBM, which is faked), hybrid OO / tie() interface, cross-platform FTPable files, and quite fast. Can handle millions of keys and unlimited hash levels without significant slow-down. Written from the ground-up in pure perl -- this is NOT a wrapper around a C-based DBM. Out-of-the-box compatibility with Unix, Mac OS X and Windows.

FileBackup is an easy-to-use backup and restore utility with GUI. It supports patch backups, soft and hard links, has an ability to backup to a standard ZIP archive, on a removable disk, FTP server or Tape unit. You can easily teach the program how to do the hard work, then you make your backups in a few steps.
Main features:
- Easy-to-use Interface - Easy-to-use GUI interface helps you start backup and restore within seconds!
- Huge storage options - Ability to backup on any kind of removable disks or to any standard FTP server gives you whole freedom where backup your data. Get all benefits of backup: compression, encryption, span disks, partial restores and others... Support of rsh is planned.
- Incremental backup archive - Smart incremental and patch backups minimize backup time by backing up only changes which were made with your files.
- Command line mode - You can start FileBackup from command line and use it in your shell scripts.
- Encryption - You can use any encryption program you want.
- Email reporting - Detailed log of backup process can be send via email to any address.
- External commands - Customize your backups by using any number of external commands before and after backup.
- Partial and full restores - When your previously good file has been corrupted or lost, the last thing you want to do is spend hours finding and restoring your system. Software has been designed to get you running fast, with minimum effort and minimum cost.