Free odbc api software for linux

ceODBC is a Python extension module that enables access to databases using the ODBC API and conforms to the Python database API 2.0 specifications with a few exceptions.
For more information on the database API specification, see here. Use the provided setup.py to build and install the module which makes use of the DistUtils module made available in Python 2.0 and up.
Enhancements:
- This release adds support for searching the catalog of a data source for tables, procedures, columns, privileges, foreign keys and primary keys.
- It also adds support for getting and setting the autocommit flag for a connection and the name for a cursor.

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

The unixODBC Project goals are to develop and promote unixODBC to be the definitive standard for ODBC on non MS Windows platforms. This is to include GUI support for both KDE and GNOME.
ODBC is an open specification for providing application developers with a predictable API with which to access Data Sources. Data Sources include SQL Servers and any Data Source with an ODBC Driver.
The two major advantages of choosing to code an application to the ODBC API are;
Portable Data Access Code
The ODBC API, as outlined by X/Open and ISO, is availible on all major platforms. Microsoft platforms include many enhancements to this specification; these enhancements are also supported by unixODBC
Dynamic Data Binding
This allows the user or the system administrator to easily configure an application to use any ODBC compliant data source. This is perhaps the single biggest advantage of coding an application to the ODBC API and to purchase these applications.
Dyamic binding allows the end-user to pick a data source, ie an SQL Server, and use it for all data applications without having to worry about recompiling the application.
The unixODBC team has reached this objective by providing the best technical solution to ODBC demands on the Linux platform. Also; ALL unixODBC development is and will be distributed under GPL or LGPL. The LGPL on libs will ensure that commercial solutions will be able to utilize unixODBC.
Enhancements:
- Fix a couple of typo errors in postgres driver and odbctest
- Fix problem where ini files could be truncated under heavy load
- Fix potential hang with FILEDSNs if the connect string included a DSN= entry as well
- Dont save the SAVEFILE attribute in the filedsn.
- Fixed bug that prevented the setting of some attributes via the DMConnAttr method
- Removed the -module entry from the cursor lib, it prevents it building on HPUX.
- Add a couple of extra info types to the pull down in odbctest
- SQLGetInfoW was returning the wrong length when converting from the ANSI call. The same was also going on the other way. Also fixed same thing for other calls.
- Fix incorrect value in SQLFetchScroll in odbctest
- Fix memory leak in odbcinstQ
- Check for MOC being found, before building GUI parts
- Add list of export symbols to libodbcinst
- Fix a problem in the cursor lib returning blobs
- SQL_DIAG_NUMBER was being stored and returned as a SQLINTEGER instead of a SQLRETURN
- Check if we can include sys/stats.h in iniOpen.c
- Fix potential buffer overun in SQLConfigDataSource()
- Fix problem in odbctest that prevented intervals from being displayed.
- Cope with SHLIBEXT not being set when finding the cursor lib
- Add a couple of missing Setup64 checks
- Small change in __info to conserve memory
- Add odbcinst.exp to distrib
- Add missing ODBC2 installer stubs
- Fix typo in SQLStatistics
- Not passing user names and password into isql passes NULLS not empty strings into SQLConnect
- Add missing SQLPrepareA from the driver manager export file
- Make the default for DontDLClose 1, it doesnt do any harm, and fixes some segfaults
- Fix printf format in the postgres driver on 64 platforms

OpenLink ODBC Bench is an open-source ODBC Benchmarking tool providing real-time comparative benchmarking for ODBC Drivers, Database Engines, and Operating Systems combinations.

The Benchmarks in this application are loosely based on the TPC-A and TPC-C standard benchmarks, with modifications to specifically test the performance of an ODBC Driver and/or Database Engine in a client/server environment.

The benchmark results can be automatically stored to an ODBC Datasource or XML file for further analysis and comparisons to be made.

ODBC-Bench is licensed under the terms of the GNU General Public License version 2.

Wikipedia API is a simple API to embed Wikipedia content dynamically on a Web site.

Wikipedia is an online encyclopedia in which the user community is encouraged to submit information for its entries. Wikipedia is unique in that it is free to the public, the content is fairly well moderated, and its content is licensed under the GFDL (GNU Free Documentation License); therefore, all of its text can be copied, modified, and used any way you see fit.

The only stipulation to using its text, is that the names of the original authors must remain intact. KillerTux.com is currently embedding some of the relevant entries in its own site and has decided to make the API open for public use. It is a simple implementation and should be easy to use. If you are a webmaster and would like to use KillerTux.coms Wikipedia API, this is the place to learn how to do it.

What is an API

An API is an application programming interface with which external applications can communicate with. The syntax and usage of the API dictates the type of data, format, and other specifics of the information to be exchanged. In this case, the API is a simple call to KillerTux.coms web server via the HTTP protocol.

Wikipedia API usage

The URL for the API is "http://scrapers.killertux.com/wikipedia-api.php". It uses the get request method and only has 3 parameters. These parameters are as follows:

wikititle=
wikiformat=[html | text]
wikiimages=[yes | no ]

The wikititle value is the name of the Wikipedia entry you are looking for, in Wikipedias variable entry. This can be found by going to Wikipedia.org and finding an entry. The name is the last part of the URL. For instance, the Wikipedia entry for "Computer Program" is "http://en.wikipedia.org/wiki/Computer_Program". Notice the space is an underscore in the URL. Defining the wikititle value for this API would look like this: wikititle=Computer_Program. This value must be specified. A sample API call would be "http://scrapers.killertux.com/wikipedia-api.php?wikititle=Computer_Program". The wikiformat value currently has two possible values: html and text. html is the default if no value is specified. If you use HTML format, it is recommended that a style sheet be used, although it may not be necessary.

A sample CSS is provided here. The text format option strips all HTML code from the document and returns plain text formatted at 80 characters per column. A sample API call would be "http://scrapers.killertux.com/wikipedia-api.php?wikititle=Computer_Program&wikiformat=html". The wikiimages value is only valid for HTML format; images for the text format are disabled. Image source locations are preserved and images are loaded from Wikipedia, not KillerTux.com. If wikiimages=no is selected, all images and captions will be striped from the document, while other HTML code should remain intact such as links to other articles. A sample API call would be "http://scrapers.killertux.com/wikipedia-api.php?wikititle=Computer_Program&wikiimages=no".

GROU.PS Web is a general purpose PHP API, created for use in Web 2.0 sites. It includes frequently used design patterns of well known web 2.0 sites. For a correct definiton of Web 2.0, you may want to check http://en.wikipedia.org/wiki/Web_2.0

Our API currently has 2 classes:

1) TagCloud?.class.php

Feed the class with your own data, and create Web 2.0 style tag clouds

2) Utility.class.php

General purpose functions. For instance getStyledDateDiff gives nicely formatted date differences that are in use in digg.com and grou.ps

The APIs are not complete yet. We are open to any ideas, wished coming from you.

Usage:

Tag Cloud Example
< ?php
require_once(/path/to/TagCloud.class.php);

$tc = new TagCloud();

$tc->setMinFontSize(8);
$tc->setMaxFontSize(20);

$tc->setDistributionType(TC_RANDOM_DISTRIBUTION);

$tc->setDataClass(tags);

$tc->addData(love,10);
$tc->addData(sex,20);
$tc->addData(food,5);
$tc->addData(business,1);
$tc->addData(PHP,2);

$res = $tc->generate();

echo $res;
? >

Utility Example:

< ?php

require_once(/path/to/Utility.class.php);

$start_date = "September 21, 1999";
$end_date = "yesterday";

$u = new Utility();

$datediff = $u->getStyledDateDiff($start_date,$end_date);

$birthday = "11 January 1978";

$zodiacsign = $u->getZodiacSign($birthday);

echo $datediff;
echo "
";
echo $zodiacsign;

? >

eBay::API is a Perl SDK for eBay Web services Interface.

SYNOPSIS

# 1. GeteBayOfficialTime use eBay::API::XML::Call::GeteBayOfficialTime;
my $pCall = eBay::API::XML::Call::GeteBayOfficialTime->new();
$pCall->execute();
my $sOfficialTime = $pCall->getEBayOfficialTime();
# 2. GetUser use eBay::API::XML::Call::GetUser; use eBay::API::XML::DataType::Enum::DetailLevelCodeType;
my $pCall = eBay::API::XML::Call::GetUser->new();
$pCall->setDetailLevel( [eBay::API::XML::DataType::Enum::DetailLevelCodeType::ReturnAll] );
$pCall->setUserID(userId);
$pCall->execute();

my $pUser = $pCall->getUser();
my $sStatusCode = $pUser->getStatus();
my $sSiteCode = $pUser->getSite();
# 3. VerifyAddItem use eBay::API::XML::Call::VerifyAddItem; use eBay::API::XML::DataType::ItemType; use eBay::API::XML::DataType::CategoryType; use eBay::API::XML::DataType::Enum::CountryCodeType; use eBay::API::XML::DataType::Enum::CurrencyCodeType; use eBay::API::XML::DataType::Enum::ListingTypeCodeType; use eBay::API::XML::DataType::Enum::BuyerPaymentMethodCodeType;
my $pItem = eBay::API::XML::DataType::ItemType->new();
$pItem->setCountry(eBay::API::XML::DataType::Enum::CountryCodeType::US);
$pItem->setCurrency(eBay::API::XML::DataType::Enum::CurrencyCodeType::USD);
$pItem->setDescription(item description.);
$pItem->setListingDuration(eBay::API::XML::DataType::Enum::ListingTypeCodeType::Days_1);
$pItem->setLocation(San Jose, CA);
$pItem->setPaymentMethods(eBay::API::XML::DataType::Enum::BuyerPaymentMethodCodeType::PaymentSeeDescription);
$pItem->setQuantity(1);
$pItem->getStartPrice()->setValue(1.0);
$pItem->setTitle(item title);

my $pCat = eBay::API::XML::DataType::CategoryType->new();
$pCat->setCategoryID(357);
$pItem->setPrimaryCategory($pCat);

my $pCall = eBay::API::XML::Call::VerifyAddItem->new();

$pCall->setItem($pItem);
$pCall->execute();

$sItemId = $pCall->getItemID()->getValue();

JXosd is a set of Java bindings for XOSD, a library for displaying information on an X display. It supports the display of text, sliders, and percentage bars through JNI. Almost the entire API has been implemented.