. . . . . . "FAQ" . . . "2018-11-19T15:17:32.776095"^^ . "FAQ" . . . . . . "2016-09-14T12:28:34.134984"^^ . "FAQ" . "2018-11-19T15:17:32Z" . . "---+ iODBC FAQ\r\n\r\n%TOC%\r\n\r\nThis document is a list of Frequently Asked Questions concerning the iODBC\r\nproject. It is currently maintained by iodbc@openlinksw.com; please\r\nfeel free to send nominations for FAQ-worthy topics to this address.\r\n\r\n---++ About iODBC.org\r\n\r\n\r\n---+++ What does iODBC stand for?\r\n\r\niODBC is an acronym for \"Independent Open Database Connectivity\". See\r\n[[About][About iODBC]] for more.\r\n\r\n\r\n---+++ Under what license is iODBC available?\r\n\r\niODBC is dual-licensed under both the\r\n[[http://www.opensource.org/licenses/bsd-license.php][BSD]] and\r\n[[http://www.opensource.org/licenses/lgpl-license.php][LGPL]] licenses.\r\n\r\nPlease see the [[License][License Page]] for more details.\r\n\r\n\r\n---+++How do I get support for iODBC\r\n\r\nSupport for iODBC is available through \r\nseveral mailing-lists hosted by\r\nSourceForge.net, where the wider community (and OpenLink employees)\r\ncontribute to the best of their ability. The previous forum has been\r\narchived but may contain useful reference material. Commercial support\r\nmay also be contracted from OpenLink Software.\r\n\r\n\r\n---+++What is the relationship between OpenLink Software and iODBC?\r\n\r\n[[http://www.openlinksw.com/][OpenLink Software]] is a software\r\ncompany specializing in data access, management, and integration technologies \r\nincluding ODBC, JDBC, ADO.NET, OLE DB, XMLA, SQL, SPARQL, and others.\r\nProducts include \r\n[[http://uda.openlinksw.com/][UDA, a suite of data access drivers/providers/connectors]] \r\nand [[http://virtuoso.openlinksw.com/][Virtuoso Universal Server]] a multi-model RDBMS.\r\n\r\niODBC is an open-source project (released under the LGPL or BSD licenses)\r\nhosted by OpenLink Software for the benefit of the wider community, to\r\nimplement and improve a free and Open ODBC Driver Manager component for\r\nLinux, macOS, Unix-like, VMS, and other platforms.\r\n\r\niODBC copyright is co-owned by Ke Jin and OpenLink Software. OpenLink are\r\nthe sole project custodian and sponsor.\r\n\r\n Advertising: OpenLink may benefit from the publicity of hosting iODBC.org,\r\nwith its links to various vendors of ODBC drivers for assorted platforms\r\nand RDBMS, but we don't set out to abuse the open-source project for\r\ncommercial gain. There are plenty of free and open-source\r\ndatabase drivers for free databases (MySQL, PostgreSQL, Firebird, and \r\nothers). The OpenLink philosophy is to facilitate OS- and\r\ndatabase-independent connectivity through ODBC, to which end having an\r\nopen-source driver-manager component is advantageous.\r\n\r\n Resources: Various OpenLink employees work on actively developing and\r\nmaintaining the authoritative CVS sources of the iODBC project,\r\nadministering the server on which the site runs, maintaining the\r\nwww.iodbc.org website, responding to posts on the public forums, etc.\r\n\r\n Executive summary: Think nice .com hosts free .org and you'll not be far\r\nfrom the truth.\r\n\r\n\r\n---+++What happened to the Forum Archive (wwwboard)?\r\n\r\nAfter a long innings, wwwboard proved too susceptible to spam and other\r\nundesirable phenomena, and the underlying wwwboard implementation was\r\nunpleasant to maintain, becoming corrupt with increasing frequency. As\r\nsuch, it has been replaced with the mailing-lists, hosted by SourceForge.\r\n\r\nIn the process, the old wwwboard has been left in stasis; a small cleanup\r\noperation was mounted to remove off-topic and dubious / offensive / illegal\r\nmaterial and links, but not extending as far as censorship: if someone said\r\niODBC or OpenLink suck, you'll see it represented as-stated there.\r\n\r\nSince then, the wwwboard service has succumbed to bitrot. Old postings may be reviewed via \r\n[[https://web.archive.org/web/20010302094845/http://195.153.164.12:80/wwwboard/wwwboard.html][archive.org]].\r\n\r\n---++Technical\r\n\r\n---+++What's an odbc.ini and what do I put in it?\r\n\r\nAn odbc.ini is the main configuration file in which all your DSNs and much\r\nof the ODBC configuration parameters are stored. iODBC has a search-path\r\nfor finding such a configuration file: first, the environment variable\r\nODBCINI is inspected to see if it points at a suitable file, or ~/.odbc.ini\r\n(analagous to User DSNs on Windows) then /etc/odbc.ini (\"system-wide\") are\r\nfall-back locations.\r\n\r\nThe odbc.ini file comprises 3 parts: a set of ODBC options, a list of DSNs,\r\nand then the datasource definitions themselves, thus:\r\n\r\n\r\n[ODBC Data Sources]\r\nPostgreSQL native localhost = PostgreSQL native driver\r\nPostgreSQL OpenLink localhost = PostgreSQL over OpenLink multi-tier\r\n\r\n[PostgreSQL native localhost]\r\nDriver = /usr/lib/postgresql/lib/libodbcpsql.so\r\nHost = localhost\r\nServer = localhost\r\nServerName = localhost\r\nDatabase = tim\r\nUserName = tim\r\nUID = tim\r\nPort = 5432\r\n\r\n[PostgreSQL OpenLink localhost]\r\nDescription = PostgreSQL, over openlink MT\r\nDriver = /opt/openlink/lib/oplodbc.so\r\nServerType = PostgreSQL95\r\nHost = localhost\r\nDatabase = tim\r\nUsername = tim\r\nLastUser = tim\r\nUser = tim\r\nFetchBufferSize = 99\r\n\r\n[ODBC]\r\n;Trace = 1\r\n;TraceFile = /tmp/odbctrace.log\r\n;Debug = 1\r\n;DebugFile = /tmp/odbcdebug.log\r\n\r\n\r\nThe list of ODBC Data Sources correlate with the file odbcinst.ini (or\r\nenvironment variable ODBCINSTINI): for every value used as a description of\r\nthe driver, there should be a corresponding section in odbcinst.ini listing\r\nboth the Driver and Setup library (to assist with graphical configuration\r\nusing iodbcadm-gtk, and also used to display an input box in the event of\r\ninsufficient options being presented at connection-time).\r\n\r\nThe list of attributes is driver-dependent, as the above shows: the native\r\npostgresql driver calls them different things from OpenLink UDA Enterprise Edition, so\r\nyou have to check your driver's documentation.\r\n\r\nWith iODBC, assuming you downloaded/installed/compiled it, you have a\r\nGTK-based GUI for configuring your ODBC DSNs, too: run iodbcadm-gtk.\r\n\r\n---+++Just get me connected!\r\n\r\nThis is the succinct overview:\r\n\r\nGrab the source. Unpack it. Run \r\n\r\n./configure && nice make && sudo make install\r\n\r\nInstall an ODBC driver for your backend database.\r\nConfigure odbc.ini to use this driver. Export the environment variable\r\nODBCINI to point to that odbc.ini. Run iodbctest and\r\nattempt to connect. Voila.\r\n\r\n---+++I've got this linux box with PHP and Apache...\r\n\r\n...and you want to connect to SQL Server or MS Access from it. The overview\r\nof the architecture is as follows: apache invokes php to handle scripts,\r\nphp is linked against libiodbc in order to handle the odbc_* functions in\r\nyour script, libiodbc loads either a native SQL Server driver for linux or\r\nsome generic ODBC-proxy for MS Access, and you're done.\r\n\r\n OpenLink produce an odbc agent that facilitates the latter sort of\r\nconnection.\r\n\r\nThe [[http://www.iodbc.org/dataspace/doc/iodbc/wiki/iodbcWiki/IODBCPHPHOWTO][iODBC+PHP+Apache HOWTO]] \r\ndocument on this site will guide you through a\r\nworking set of configure options for libiodbc, apache, and php in order.\r\n\r\n\r\n---+++What's a libiodbc and what goes in my Driver= lines in odbc.ini?\r\n\r\nThe ODBC architecture separates the application, the driver-manager and the\r\ndriver components, each one calling the next in a chain.\r\n\r\nThe libiodbc.so library only implements a driver manager; you need a\r\nseparate driver for each kind of backend database to which you connect, but\r\nyour application will at least see one consistent interface across all of\r\nthem. If you attempt to use Driver=libiodbc.so in the odbc.ini, it will\r\nfail.\r\n\r\nThe Driver= parameter should be a full name to a shared-library\r\nimplementing the driver for the backend database to which you're\r\nconnecting:\r\n\r\n\r\n[pglocal]\r\nDriver = /usr/local/lib/psqlodbc.so\r\nPort = 5432\r\nServerName = localhost\r\nDatabase = me\r\nUserName = me\r\nPassword =\r\n\r\n[OpenLink]\r\nDescription = PostgreSQL, over openlink multi-tier\r\nDriver = /opt/openlink/bin/oplodbc.so\r\nServerType = PostgreSQL95\r\nHost = otherbox\r\nDatabase = me\r\nUsername = me\r\nFetchBufferSize = 99\r\n\r\n\r\nMore recent versions of iODBC permit use of { } for quotations and\r\nsymbolic names for the driver (referencing the odbcinst.ini file), such as\r\n\r\n\r\nDriver = {SQL Server}\r\n\r\n\r\nOlder versions of iODBC implemented neither of these; the Driver= \r\nparameter had to be a full path directly to the shared library. \r\n\r\n---++Common Error Messages\r\n\r\n---+++[iODBC][Driver Manager]Data source name not found and no default driver specified. Driver could not be loaded, SQLSTATE=IM002\r\n\r\n\r\nThere are several reasons why this message could occur. The best solution\r\nis to trace through what's happening: your application has been linked\r\nagainst libiodbc, which has tried to find an odbc.ini file one way or\r\nanother - either through the ODBCINI environment variable or the fall-back\r\npaths (typically /etc/odbc.ini, depending on how it was compiled). You\r\nshould check that such a file exists in a suitable location, and that it is\r\naccessible (particularly if your application runs with different user\r\nprivileges - such as apache/php running as a www-data user).\r\n\r\nAdditionally, it could be that iODBC has found a suitable odbc.ini file,\r\nbut none of the file(s) found contain the DSN you've requested. Check the\r\nsyntax of your request - is the ODBC connect-string correct, and does the\r\nDSN you're requesting exist? See also the section of this FAQ \r\nentitled [[#What%27s%20an%20odbc.ini%20and%20what%20do%20I%20put%20in%20it%3F][What's an odbc.ini and what do I put in it?]]\r\n\r\n\r\n---+++[iODBC] [Driver Manager]Specified driver could not be loaded\r\n\r\nAs in the previous error case, there are a few reasons why this could\r\noccur, and thinking through the architecture helps. Your application has\r\nloaded libiodbc successfully, and it has found an odbc.ini file (or\r\nequivalent through the ODBCINI environment variable), and it has found a\r\nDSN within that odbc.ini that matches the name requested in your\r\nconnection.\r\n\r\nHowever, the driver manager has had problems loading the library specified\r\nin the Driver= line of that DSN definition. Either it doesn't exist, or\r\nits permissions are insufficient to allow your application to load it (it\r\nmust be readable and executable, and the directories leading down to it\r\nmust be executable), or maybe the file is not a dynamic library -- it could\r\nbe a static library (a *.a file, except on AIX) -- or is otherwise corrupted.\r\nThese are all things to check, or you may be best off reinstalling the\r\ndriver if all the permissions check out.\r\n\r\nNote also the prior point: the Driver= parameter must lead to\r\na shared-library (*.so) implementing an ODBC driver for the database to\r\nwhich you're connecting.\r\n\r\n---++Driver-Specific Errors\r\n\r\n---+++MyODBC: [TCX][MyODBC]No DSN entered (0) SQLSTATE=S1000\r\n\r\nThis error is raised whenever you attempt to connect to MyODBC using the\r\nSQLDriverConnect() function with the SQL_DRIVER_PROMPT option. Normally,\r\nSQL_DRIVER_PROMPT means the driver should invoke a graphical dialog to\r\nrequest missing information (DSN=, or username and password if not\r\nincluded); however, MyODBC has no graphical library and does not\r\ndistinguish the case that a graphical prompt is unavailable from when there\r\nis insufficient information, so you always see this error message.\r\n\r\niodbctest and iodbctestw from versions 3.52.1 and 3.52.2 both request\r\nconnections using SQL_DRIVER_PROMPT, causing this problem with MyODBC.\r\n\r\nThe workaround is to edit iodbctest.c such that the SQLDriverConnect() and\r\nSQLDriverConnectW() calls use SQL_DRIVER_COMPLETE instead. This still\r\nallows drivers with graphical setup routines to ask for additional\r\ninformation, but works better with drivers that have no graphical routines,\r\nsuch as MyODBC. See the following diff:\r\n\r\n\r\n\r\nIndex: iodbctest.c\r\n===================================================================\r\nRCS file: /opldev/opensource/iODBC/samples/iodbctest.c,v\r\nretrieving revision 1.22\r\nretrieving revision 1.21\r\ndiff -u -u -r1.22 -r1.21\r\n--- iodbctest.c 2005/07/19 10:19:01 1.22\r\n+++ iodbctest.c 2005/02/15 17:08:13 1.21\r\n@@ -297,12 +297,12 @@\r\n#ifdef UNICODE\r\nstrcpy_A2W (wdataSource, (char *) dataSource);\r\nstatus = SQLDriverConnectW (hdbc, 0, (SQLWCHAR *) wdataSource, SQL_NTS,\r\n- (SQLWCHAR *) outdsn, NUMTCHAR (outdsn), &buflen, SQL_DRIVER_COMPLETE);\r\n+ (SQLWCHAR *) outdsn, NUMTCHAR (outdsn), &buflen, SQL_DRIVER_PROMPT);\r\nif (status != SQL_SUCCESS)\r\nODBC_Errors (\"SQLDriverConnectW\");\r\n#else\r\nstatus = SQLDriverConnect (hdbc, 0, (SQLCHAR *) dataSource, SQL_NTS,\r\n- (SQLCHAR *) outdsn, NUMTCHAR (outdsn), &buflen, SQL_DRIVER_COMPLETE);\r\n+ (SQLCHAR *) outdsn, NUMTCHAR (outdsn), &buflen, SQL_DRIVER_PROMPT);\r\nif (status != SQL_SUCCESS)\r\nODBC_Errors (\"SQLDriverConnect\");\r\n#endif\r\n\r\n\r\nThis change is included in the iODBC 3.52.3 and later.\r\n\r\n---++Segfault with Perl DBD::ODBC\r\n\r\nCertain platforms (most notably Debian GNU/Linux 5.0.4 (\"Lenny\", currently \r\nstable)) ship with version 1.13-5 of Perl's DBD::ODBC module. On 64-bit OS, \r\nthis has a bug that causes a segfault. The solution is to upgrade to at least \r\n1.17 (may be found in \"Squeeze\", currently the Testing distribution).\r\n\r\n---++Tracing Application Behavior\r\n\r\nIn the above odbc.ini snippet, we saw commented-out lines concerning\r\ntracing. These lines would enable us to analyze what ODBC calls the driver\r\nmanager sees an application make, with details including parameters, return\r\nstates, etc.\r\n\r\nTo enable this, uncomment the lines in your odbc.ini:\r\n\r\n\r\n\r\n[ODBC]\r\nTrace = 1 \r\nTraceFile = /tmp/odbctrace.log \r\nDebug = 1 \r\nDebugFile = /tmp/odbcdebug.log\r\n\r\n\r\nIn iODBC version 3.51.0 and above, the TraceFile option now understands\r\na handful of variables:\r\n\r\n\r\n$P Process ID\r\n$U User ID under which the process is currently running\r\n$T Timestamp in YYYYMMDDHHMMSS format\r\n$H Home directory of the user that started the process\r\n\r\n\r\nAlso, from version 3.52.7 onwards, TraceFile now takes an option\r\n\r\n\r\n$S Sequence number\r\n\r\n\r\nThese are case-insensitive. Hence you could specify -- \r\n\r\n\r\nTraceFile=/tmp/iodbc-$U-$P-$T.log\r\n\r\n\r\n-- and it would include your userid, the application process-id, and the timestamp\r\nwhen ODBC was invoked, in the trace log filename.\r\n\r\n\r\n---+++Tracing Application Behavior\r\n\r\nAs of release 3.52.5, iODBC has support for File DSNs - where the\r\nconnection parameters are stored in a separate file per DSN, under a\r\nstandard directory.\r\n\r\nTo configure these, either use the FileDSN tab alongside System and User\r\nDSNs in the iODBC graphical administrator (iodbcadm-gtk or the macOS\r\nGUI), or edit files in /etc/ODBCDataSources/ for yourself.\r\n\r\n\r\n\r\n\r\nNote that this directory must have suitable permissions for those you wish\r\nto be able to create, edit, and remove files to do so. For example, 1775\r\nmight be suitable - the owner and members of the group owning the directory\r\ncan create, remove, and edit their own DSNs, but not those owned by a\r\ndifferent user.\r\n\r\nTo use a File DSN, replace the DSN= parameter in your ODBC connection\r\nstring with FileDSN=, for example\r\n\r\n\r\n\r\niodbctest FileDSN=localvirtuoso;UID=dba;PWD=secret\r\n" . . . . . . . "2016-09-14T12:28:34Z" . . "7c359733d029b0f601c914309377ae50" . . . . .