odbc_connect
(PHP 4, PHP 5)
odbc_connect — Connect to a datasource
Description
Returns an ODBC connection id or 0 (FALSE) on error.
The connection id returned by this functions is needed by other ODBC functions. You can have multiple connections open at once as long as they either use different db or different credentials. The optional fourth parameter sets the type of cursor to be used for this connection. This parameter is not normally needed, but can be useful for working around problems with some ODBC drivers.
With some ODBC drivers, executing a complex stored procedure may fail with an error similar to: "Cannot open a cursor on a stored procedure that has anything other than a single select statement in it". Using SQL_CUR_USE_ODBC may avoid that error. Also, some drivers don't support the optional row_number parameter in odbc_fetch_row(). SQL_CUR_USE_ODBC might help in that case, too.
The following constants are defined for cursortype:
- SQL_CUR_USE_IF_NEEDED
- SQL_CUR_USE_ODBC
- SQL_CUR_USE_DRIVER
- SQL_CUR_DEFAULT
For persistent connections see odbc_pconnect().
- PHP Руководство
- Функции по категориям
- Индекс функций
- Справочник функций
- Расширения для работы с базами данных
- Уровни абстракции
- ODBC (Unified)
- odbc_autocommit
- odbc_binmode
- odbc_close_all
- odbc_close
- odbc_columnprivileges
- odbc_columns
- odbc_commit
- odbc_connect
- odbc_cursor
- odbc_data_source
- odbc_do
- odbc_error
- odbc_errormsg
- odbc_exec
- odbc_execute
- odbc_fetch_array
- odbc_fetch_into
- odbc_fetch_object
- odbc_fetch_row
- odbc_field_len
- odbc_field_name
- odbc_field_num
- odbc_field_precision
- odbc_field_scale
- odbc_field_type
- odbc_foreignkeys
- odbc_free_result
- odbc_gettypeinfo
- odbc_longreadlen
- odbc_next_result
- odbc_num_fields
- odbc_num_rows
- odbc_pconnect
- odbc_prepare
- odbc_primarykeys
- odbc_procedurecolumns
- odbc_procedures
- odbc_result_all
- odbc_result
- odbc_rollback
- odbc_setoption
- odbc_specialcolumns
- odbc_statistics
- odbc_tableprivileges
- odbc_tables
Коментарии
Alot of people share the same kind of problems getting this setup on linux. I was assigned this problem 2 days ago and I was successful. My combination was PHP4 RC2, Easysoft OOB, and unixODBC. These three products work very well together and are real easy to install. More info http://www.easysoft.com/products/oob/main.phtml. ps also works good with Perl's DBI.If using Openlink to connect to a Microsoft Access database, you will most likely fine tha odbd_connect() works fine, but discover that ANY query will produce odd results; with SELECT queries failing with "[OpenLink][ODBC][Driver]Driver not capable, SQL state
S1C00 in SQLExecDirect in xxxx.php on line xx" and INSERT / DELETE queries warning "No tuples available at this result index".
In this case, use the SQL_CUR_USE_ODBC cursor!
This had me stumped for quite some time; because it was the odbc_exec() which was seemingly at fault... :)
Siggy
If like me you are using openlink from unix to access an MS Access database on an NT/Win2k machine and find out that your INSERT queries don't do anything and don't report any errors, use odbc_pconnect().
I couldn't understand what was going on and after a bit of research I found out that with MySQL they recommended using mysql_pconnect() for INSERT queries. I tried the same thing with odbc and it worked.
If you don't want to specify your login credentials on your web server, you can leave the login fields blank to use the integrated windows security like here:
odbc_connect("DSN=DataSource","","");
Make sure you have switched your system dsn to integrated security, too !
(works on windows machines only, of course)
flo.
We've tried hard to connect from php to our IBM DB2 RS/6000 Server. It worked after we compiled with --ibm-db2= option, but it was unbelievable
slow.
No, just testing some options, we found out that it went from very slow (getting 100 records lasts 1 till 10 seconds) to fast access (almost same speed as with using JDBC from Servlets) to 0.2 till 0.3 seconds.
We simply added the optional parameter Cursortype to odbc_connect, and with the cursortype SQL_CUR_USE_ODBC it changed in that way!
Hope this helps anybody who must connect to db2 ;)
// simple conection
$cnx = odbc_connect('cliente','Administrador','');
//query
$SQL_Exec_String = "select * from Clientes";
//ejecucion query
$cur= odbc_exec( $cnx, $SQL_Exec_String );
echo "<table border=1><tr><th>Dni</th><th>Nombre</th>".
"<th>codigo</th><th>ciudad</th></tr>\n";
while( odbc_fetch_row( $cur ) ) {
$Dni= odbc_result( $cur, 1 );
$Nombre= odbc_result( $cur, 2 );
$codigo= odbc_result( $cur, 3 );
$ciudad= odbc_result( $cur, 4 );
echo "<tr><td>$Dni</td><td>$Nombre</td>".
"<td>$codigo</td><td>$ciudad</td></tr>\n";
}
echo "</table>";
WINNT 4 Workstation, PHP4
odbc_connect() kept giving me weird errors when trying to connect to a MSaccess DSN(Microsoft Jet engine couldn't open the database 'Unknow'. Another user is using it exclusively, or you dont have permission to use it).
After going nuts for a while, I realized that my database name had a space in it (course surveys.mdb), I shortened the name to eliminate the space .. and everything worked fine.
Thought I'd add a note here on this. I'm using Apache 2.0.39 on Windows XP and PHP 4.2.2.
It helps a lot if you don't use capital letters in your dsn string.
Thought I also comment on the posts about using system dsns over file dsns. There are lots of posts saying use systems not files, but none (that I have seen) which explain why.
Essentially: File DSNs are specific to the current user, therefore the Internet Guest User Account doesn't have rights to them. Systems are available to everyone.
Regards
Osiris :)
here's a quick note about using php and db2 that cost me a couple of hours and several recompiles trying to figure out why it didn't work.
put the below line in any script
putenv("DB2INSTANCE=db2inst1");
Or, set that in your webserver environment somehow.
As always Microsoft is clueless... I've been trying to connect to an Access database on a W2K on the network (not a local file, but mapped on the V: drive), via ODBC.
All I got is this message:
Warning: SQL error: [Microsoft][ODBC Microsoft Access Driver] '(unknown)' is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides., SQL state S1009 in SQLConnect in d:\apache\cm\creaart.php on line 13
So... I started looking al around and looks like the ODBC driver has some severe problems:
1. It cannot access a Access database via a mapped drive. And this is for ANY application, name it PHP, Coldfusion, whatever
2. You cannot make a system DSN with a UNC (\\Server\resource), so you must map the drive
Cute isn't it?
So... I quit on ODBC and went via ADO, this is the code that works:
=== CODE ===
$db = '\\\\server\\resource\\db.mdb';
$conn = new COM('ADODB.Connection');
$conn->Open("DRIVER={Driver do Microsoft Access (*.mdb)}; DBQ=$db");
// Driver do Microsoft Access (*.mdb)
// must be the name in your odbc drivers, the one you get
// from the Data Sources (ODBC).
// In this case, I'm in Mexico but the driver name is in portuguese, thanks Microsoft.
$sql = 'SELECT username FROM tblUsuarios';
$res = $conn->Execute($sql);
while (!$res->EOF)
{
print $res->Fields['username']->Value . "<br>";
$res->MoveNext();
}
$res->Close();
$conn->Close();
$res = null;
$conn = null;
=== /CODE ===
Connect to an MS-Access Database on the Network via ODBC
Apache 2.0.47 with PHP 4.3.4 running on Windows XP Pro
If you encounter the error
"[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified, SQL state IM002 in SQLConnect"
you should make sure to have the following done:
The ODBC-link must be a System-DNS and not a User-DNS. Configure your ODBC-link and then modify your configuration with regedt32. Go to HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC_INI and open your ODBC-link. The field DBQ contains the path to your database. This path must be without Drive-names (e. g. "M:") so change it to "\\Server\folder\database.mdb". This setting is changed each time you modify your ODBC-configuration using the Windows-tool, so make sure you do this afterwards.
Then you go to the Services-Section in your Systemmanagement. Select the properties of your Apache module. In the login-section you have to make sure you login with a valid User-Account for your Network-Server.
Please note that this way you still have no permission to access linked tables within the linked database
Funny enough all this is not necessary on Win98.
To connect to a SQL DB on a unix srv via odbc one can use one of the following solutions.
1. having an odbc.ini (~/.odbc.ini)
[PostgreSQL]
Description = PostgreSQL template1
Driver = PostgreSQL
Trace = Yes
TraceFile = /tmp/odbc.log
Database = PerfTest
Servername = localhost
UserName = boss
Password = BigBoss
Port = 5432
Protocol = 6.4
ReadOnly = Yes
ConnSettings =
[Default]
Driver = /local/lib/libodbc.so
2. specifying a DSN
function DBCALL($SQL)
{
$U = "boss";
$DB = "PerfTest";
$P = "BigBoss";
$Srv = "llocalhost";
$DSN = "Driver=PostgreSQL;Server=$Srv;Database=$DB";
echo "Trying to connect to $DSN\n";
if ($CID = odbc_connect ("$DSN","$U","$P",SQL_CUR_USE_ODBC))
{
echo "still trying CID = $CID\n";
if ($RES = odbc_exec($CID, $SQL))
{
echo "RES = $RES\n";
print_r($RES);
echo "\n";
$NR = odbc_num_rows($RES);
<snip>
Hope this helps.
To make a DSN-less connection using ODBC to MS-SQL:
<?php
$connection_string = 'DRIVER={SQL Server};SERVER=<servername>;DATABASE=<databasename>';
$user = 'username';
$pass = 'password';
$connection = odbc_connect( $connection_string, $user, $pass );
?>
servername is the name of the database server
databasename is the name of the database
Note, I've only tried this from a windows box using the Microsoft ODBC drivers.
To connect to Sybase SQL Server Anywhere 8.0 on Windows use the following:
<?php
//================================================================
// Configure connection parameters
$db_host = "server.mynetwork";
$db_server_name = "Dev_Server";
$db_name = "Dev_Data";
$db_file = 'c:\dbstorage\dev.db';
$db_conn_name = "php_script";
$db_user = "dbuser";
$db_pass = "dbpass";
//================================================================
$connect_string = "Driver={Adaptive Server Anywhere 8.0};".
"CommLinks=tcpip(Host=$db_host);".
"ServerName=$db_server_name;".
"DatabaseName=$db_name;".
"DatabaseFile=$db_file;".
"ConnectionName=$db_conn_name;".
"uid=$db_user;pwd=$db_pass";
// Connect to DB
$conn = odbc_connect($connect_string,'','');
// Query
$qry = "SELECT * FROM my_table";
// Get Result
$result = odbc_exec($conn,$qry);
// Get Data From Result
while ($data[] = odbc_fetch_array($result));
// Free Result
odbc_free_result($result);
// Close Connection
odbc_close($conn);
// Show data
print_r($data);
//================================================================
?>
Two additional notes regarding ODBC connections to a Network Sybase SQL Anywhere 8 Server..
I wrote a script using the PHP5 CLI binary that monitors a directory for changes, then updates a Network Server SQL Anywhere 8 database when a change was detected. Idealy, my program would run indefinately, and issue odbc_connect()/odbc_close() when appropriate. However, it seems that once connected, your odbc session is limited to 30 seconds of active time, after which, the connection becomes stale, and no further queries can be executed. Instead, it returns a generic "Authentication violation" error from the odbc driver.
Here's an example:
<?php
$conn=odbc_connect($connect_string,'','');
$result=odbc_exec($qry,$conn); //returns data
sleep(31);
$result=odbc_exec($qry,$conn); //"Authentication Violation"
?>
Additionally, it seems that odbc_close() doesn't truely close the connection (at least not using Network SQL Anywhere 8). The resource is no longer usable after the odbc_close() is issued, but as far as the server is concerned, there is still a connection present. The connection doesn't truely close until after the php script has ended, which is unfortunate, because a subsequent odbc_connect() commands appear to reuse the existing stale connection, which was supposedly closed.
My workaround was to design my script exit entirely after a the database update had completed. I then called my script whithin a batch file and put it inside an endless loop.
I'm not sure if this is a bug with PHP or what, but I thought I'd share in case someone else is pulling their hair out trying to figure this one out...
For three days I fought to be able to connect our Linux intranet server to our AS400 database through ODBC and PHP on Mandrake. I installed everything I thought would work but I still got a: odbc_connect(): SQL error: Missing server name, port, or database name in call to CC_connect., SQL state IM002 in SQLConnect
Note that isql was working great but php was failing to connect.
The solution:
I located and found a PHP module called php-unixODBC (to oppose with php-odbc). Once installed (even though it wasn't for the right version of PHP), I realised it didn't place the file properly. The ini file was in /etc/php/ instead of /etc/php.d/, so I moved it there and renamed the old /etc/php.d/36_odbc.ini to /etc/php.d/36_odbc.ini.sav, so that I now had /etc/php.d/36_unixodbc.ini. I restarted the httpd server and now I was able to access the as400.
If you have questions, email _artaxerxes2_at_iname_dot_com (sans the underscore).
For anyone having problems with WHERE clauses in their MS Access ODBC requests here?s what I found: SQL requests sent to Access must include quotes around the criteria.
$sel = "SELECT * FROM table1 WHERE cust_id = 'cust1'";
outputs:
SELECT * FROM table1 WHERE cust_id = 'cust1'
And works.
$sel = ?SELECT * FROM table1 WHERE cust_id = cust1?;
outputs:
SELECT * FROM table1 WHERE cust_id = cust1
And doesn?t work.
Here?s the whole block of code:
$conn = odbc_connect("database1","","");
$sel = "SELECT * FROM table1 WHERE cust_id = 'cust1'";
$exec = odbc_exec($conn,$sel);
while($row = (odbc_fetch_array($exec)))
$serv[odbc_result($exec,'label')] = $row;
print_r($serv);
Concerning the note posted by Grisu on the 23-Dec-2003 11:51: Connect to an MS-Access Database on the Network via ODBC,
PLEASE dont forget to put double slashes as follows:
"\\\\Server\\folder\\database.mdb"
when setting up the registry key as indicated...
I also had a problem with this message: ([ODBC SQL Server driver]Allocation of a Sybase Open Client Context failed). The message only appeared after the server had run for a few hours, so I expected resource starvation. However it was a settings problem and I thought this might benefit others too.
In addition to putting a <?php putenv ("SYBASE=c:\sybase"); ?> as described by oottavi above, I also had so specify a locale by setting <?php putenv ("LC_ALL=default"); ?>.
Even though my locale was already set to a valid one (en_US) I had to set this environment variable to make it work anyhow.
Hi,
Instructions on how to connect to a Progress database on Linux using the Merant ODBC driver can be found at http://www.progteg.com/english/documents.html.
Kind regards,
Sven Delmeiren
Computers & Communications NV
"Returns an ODBC connection id or 0 (FALSE) on error."
Keep in mind that the following code in PHP5 will not work properly:
<?php
if( odbc_connect("test", "test", "test") === false ) {
// Your error reporting/handling here..
}
?>
odbc_connect() returns an integer, and not a PHP5 boolean!
I have used mdbtools to access .mdb file on my ubuntu box, as ODBC driver (and PHP)It has very few features, and practically unusable.
This might be obvious to some, but here is a quick tidbit that might save you some time if you're using FreeTDS in Linux:
Be sure that you have these two lines in freetds.conf:
dump file = /tmp/freetds.log
dump file append = yes
so you can tail -f it in the background of debugging the problem. This helped me find my issue on on CentOS Linux:
1) tsql test works
2) isql test works
3) odbc connection in php also works WHEN RUN FROM THE SHELL
4) running PHP through apache does NOT work.
my /tmp/freetds.log file told me:
net.c:168:Connecting to MYDBSERVER port MYDBPORT
net.c:237:tds_open_socket: MYDBSERVER:MYDBPORT: Permission denied
and the answer was my firewall/SELinux was denying the Apache processes access to connect to the remote MSSQL DB port, but my shell accounts were fine.
[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
If you keep running into this on the 64 bit versions of windows, ie server 2008, and none of the other solutions helped.
In a 64 bit windows server operating system, there are TWO odbc managers. When you pull up the usual menu for the odbc / dsn system, it is for the 64 bit odbc manager, and 32 bit applications (vb 6.0, PHP 5) will not work using these dsn's.
This is where the 32 bit odbc manager is:
C:\Windows\SysWOW64\odbcad32.exe
Here is my successful odbc_connect with mysql on Ubuntu. It took me a while to figure this out.
Installed following packages using apt-get.
apache2
apache2-mpm-prefork
apache2-utils
apache2.2-common
libapache2-mod-php5
libdbd-mysql-perl
libmyodbc
libmysqlclient15off
mysql-client-5.0
mysql-common
mysql-server-5.0
mysql-server-core-5.0
odbcinst1debian1
php5
php5-cli
php5-common
php5-odbc
unixodbc
/etc/odbc.ini
------------
myodbc3 = MySQL ODBC 3.51 Driver
[myodbc3]
Driver = /usr/lib/odbc/libmyodbc.so
Description = MySQL ODBC 3.51 Driver
Server = localhost
Port = 3306
User = shyam
Password = mypass
Database = mysql
Option = 3
Socket = /var/run/mysqld/mysqld.sock
/etc/odbcinst.ini
----------------
[MySQL ODBC 3.51 Driver]
Description = MySQL driver
Driver = /usr/lib/odbc/libmyodbc.so
Setup = /usr/lib/odbc/libodbcmyS.so
CPTimeout =
CPReuse =
UsageCount = 1
my php script
------------
<html>
<body>
<?
$conn = odbc_connect("DRIVER={MySQL ODBC 3.51 Driver};Server=localhost;Database=mysql", "shyam", "mypass");
$sql = "SELECT user from user";
$rs = odbc_exec($conn,$sql);
echo "<table><tr>";
echo "<th>User Name</th></tr>";
while (odbc_fetch_row($rs))
{
$user = odbc_result($rs,"user");
echo "<tr><td>$user</td></tr>";
}
odbc_close($conn);
echo "</table>";
?>
</body>
</html>
Once you've set up a UnixODBC connection to Informix (as described elsewhere, for example in http://www.unixodbc.org/), the following PHP code will access a database via its DSN:
<?php
// We must set these environment variables for Informix to work. Either
// do it here or in php.ini.
putenv("INFORMIXDIR=/usr/share/informix");
putenv("ODBCINI=/usr/local/unixODBC/etc/odbc.ini");
// Open up a connection to the database.
if (!($con = odbc_connect("CollectOh", "", "")))
echo "<p>Connection to CollectOh failed.</p>\n";
else
{
// Let's try enumerating all of the tables in the database (there ain't
// no "show tables" here).
if (($res = odbc_exec($con, "select * from SYSTABLES")))
{
echo "<p>\n";
odbc_result_all($res);
echo "</p>\n";
}
// Close up shop, like good dobies.
odbc_close($con);
}
?>
Pls ensure that the MSAccess database format is ".mdb".If it is ".accdb" it will not work!
/* Connecting to Microsoft Access with PHP
$conn = odbc_connect("Driver={Microsoft Access Driver (*.mdb)};
Dbq=$mdb_Filename", $user, $password);
This does NOT work on Windows servers.
Instead, it needs
$conn->Open("Provider=Microsoft,.Jet.OLEDB.4.0; Data Source=......
Point the variable $mdb_Filename to...
Data Source=C:\inetpub\wwwroot\php\mdb_Filename
or wherever the virtual directory points.
Under Windows odbc_connect (and PDO ODBC) apparently uses the Windows locale to handle input and output from e.g. MS access and MS SQL Server databases.
This causes lots of headaches if one is using other than ASCII characters.
Work-round solutions like utf8_encode and mb_convert both fails.
The solution I fund working is to perform the following changes to Windows
Control Panel > Region > Administrative > Change system locale
>Check '<i>Use Unicode UTF-8 for worldwide language support.</i>'
One additional note regarding odbc_pconnect and possibly other variations of pconnect:
If the connection encounters an error (bad SQL, incorrect request, etc), that error will return with be present in odbc_errormsg for every subsequent action on that connection, even if subsequent actions don't cause another error.
For example:
A script connects with odbc_pconnect.
The connection is created on it's first use.
The script calls a query "Select * FROM Table1".
Table1 doesn't exist and odbc_errormsg contains that error.
Later(days, perhaps), a different script is called using the same parameters to odbc_pconnect.
The connection already exists, so it is reused.
The script calls a query "Select * FROM Table0".
The query runs fine, but odbc_errormsg still returns the error about Table1 not existing.
I'm not seeing a way to clear that error using odbc_ functions, so keep your eyes open for this gotcha or use odbc_connect instead.