I have a system that is running php, and I recently needed to add connectivity to an MSSQL database. I have FreeTDS and UnixODBC installed/configured correctly, and I can make successful queries in python, and via utilities like tsql and isql. After looking at phpinfo() I've discovered I don't have a 'sqlsrv' section, and there is no mssql.so file in my php extensions directory.
I want to add this to my system without having to recompile/install php. Would I be able to find and download the mssql.so file, put it into my extensions directory, add extension=/path/to/mssql.so to my php.ini file, and reload apache to get this working? Or is there more steps I would need to take?
EDIT:
The system is running SLES11 with PHP 5.2
EDIT 2:
I've managed to get the php5-mssql extension installed. I grabbed the source, extracted it, and copies these files:
ext/mssql/config.m4
ext/mssql/php_mssql.c
ext/mssql/php_mssql.h
Then, in the directory where I copied the files to, I ran phpize (you will need to install php5-devel to get this tool), and compiled the extension like so:
./configure --with-mssql=/usr/local/freetds
make
I also had to add a line and comment out a line in php_mssql.c before it could actually compile correctly (not everyone will need to do this):
{NULL,NULL,NULL}
/*PHP_FE_END*/
This created the mssql.so file in /php_mssql/modules/ (relative to where I compiled the code), which I was able to move to my extensions directory (you can find this with php -i | grep extensions). I added extension=mssql.so to my php.ini file; however, there is still no 'sqlsrv section in phpinfo().
Some connection methods seem to partially work:
When running the following code from a shell, <h1>Connection Success</h1> is shown; but when opened in a browser, nothing after the mssql_connect line is shown:
<?php
//*************************************************************************
//Open Database Connection
//*************************************************************************
//phpinfo();
$dbserver="MyServer";
$dbusername="user";
$dbpassword="pass";
$defaultdb="DBName";
$cn = mssql_connect($dbserver,$dbusername,$dbpassword) or die("Connection Error");
$db = mssql_select_db($defaultdb,$cn) or die("Database Error");
echo "<h1>Connection Success</h1>";
?>
So it looks like I'm partially getting a connection that way? When I try with a PDO object, I get another error:
Code:
<?php
$con = new PDO('odbc:host=MyServer;dbname=DBName','user','pass');
?>
Error:
PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[IM002] SQLDriverConnect: 0 [unixODBC][Driver Manager]Data source name not found, and no default driver specified' in /path/to/php/file/test3.php:3
Stack trace:
#0 /path/to/php/file/test3.php(3): PDO->__construct('odbc:host=MySer...', 'user', 'pass')
#1 {main}
thrown in /path/to/php/file/test3.php on line 3
I've also tried the following (assuming that the PDO statement/DSN in the previous code was incorrrect):
<?php
try {
$db = new PDO("odbc:Driver=FreeTDS; Server=MyServer; Port=1433; Database=DBName; UID=user; PWD=pass;");
} catch (PDOException $exception) {
die("$exception");
}
echo "<h1>Success!</h1>";
?>
This showed <h1>Success!</h1> from the shell, but showed the following error in my web browser:
exception 'PDOException' with message 'SQLSTATE[08001] SQLDriverConnect: 0 [unixODBC][FreeTDS][SQL Server]Unable to connect to data source' in /path/to/php/file/test4.php:3 Stack trace: #0 /path/to/php/file/test4.php(3): PDO->__construct('odbc:Driver=Fre...') #1 {main}
In ODBC the error message contains elements in [] at the start of the message and the rightmost one is the part of the chain reporting the error (see ODBC Diagnostics & Error Status Codes. So, "[unixODBC][Driver Manager]Data source name not found, and no default driver specified" was reported by unixODBC. What unixODBC is saying is the string passed to the ODBC API SQLConnect or SQLDriverConnect does not identify a DSN (data source name) or an ODBC driver and there is no default DSN defined. You can find where your data sources are defined by running odbcinst -j e.g.,
$ odbcinst -j
unixODBC 2.2.14
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /home/martin/.odbc.ini
SQLULEN Size.......: 4
SQLLEN Size........: 4
SQLSETPOSIROW Size.: 2
Here, drivers are defined in /etc/odbcinst.ini, system data sources in /etc/odbc.ini and user data sources in /home/martin/.odbc.ini. As you'll probably be running PHP probably under a web server I'd stick to using the system data sources if I were you. You can list your system data sources with odbcinst -q -l -s. You find a a very good explanation of Linux/ODBC at Linux/UNIX ODBC.
Your second error "[unixODBC][FreeTDS][SQL Server]Unable to connect to data source" is reported by the SQL Server driver from FreeTDS so in this case you must have passed sufficient information to unixODBC to at least allow it to identify the driver, load it and call SQLConnect/SQLDriverConnect in it. You can see what was passed to unixODBC's SQLConnect/SQLDriverConnect by enabling tracing in unixODBC. You enable tracing of unixODBC by editing your odbcinst.ini file (locate with odbcinst -j command above) and adding the following to the top of it:
[ODBC]
Trace = yes
TraceFile = /tmp/unixodbc.log
Now, when you run your php example it will log to /tmp/unixodbc.log all ODBC API calls and the one you are looking for is SQLConnect or SQLDriverConnect. e.g., when I connect to a DSN called mydsn with a username and password of XXX and YYY I see:
[ODBC][31521][1374740062.012973][SQLDriverConnect.c][687]
Entry:
Connection = 0x9d7d430
Window Hdl = (nil)
Str In = [DSN=mydsn;UID=XXX;PWD=********][length = 29]
Str Out = 0xbfdeb83c
Str Out Max = 512
Str Out Ptr = 0xbfdeb638
Completion = 0
UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'
DIAG [01000] [Easysoft][SQL Server Driver][SQL Server]Changed database context to 'master'.
DIAG [01000] [Easysoft][SQL Server Driver][SQL Server]Changed language setting to us_english.
Note, this connection was successful and it clearly shows part of the connection string was DSN=mydsn and mydsn exists as a DSN in my /etc/odbcinst.ini.
isql can work differently to some ODBC enabled applications as isql calls the ODBC API SQLConnect whereas most ODBC applications these days are ODBC 3 aware and use SQLDriverConnect. The main difference is SQLConnect is only given 3 arguments, a DSN name, a username and a password where SQLDriverConnect is given a single string of attribute/value pairs defining the connection. I only tell you this so you are aware how it is possible for isql to work and something else not to.
However, in your second case when you examine your trace you'll see unixODBC got something useful enough to identify the driver, load it and call freeTDS's ODBC driver and the error "Unable to connect to data source" is coming from freeTDS. So, I suggest your DSN is probably ok and your freetds.conf is incorrect in some way. As I don't use freeTDS myself I'm not sure but I've heard you can use ODBC with freeTDS without any reference to the freetds.conf file and switches based on whether you use Server or ServerName. I'm sure there are loads of examples on the freeTDS web site.
Here's how I connect to MS SQL servers from a LAMP (Ubuntu) stack:
/etc/odbc.ini
# Define a connection to a Microsoft SQL server
# The Description can be whatever we want it to be.
# The Driver value must match what we have defined in /etc/odbcinst.ini
# The Database name must be the name of the database this connection will connect to.
# The ServerName is the name we defined in /etc/freetds/freetds.conf
# The TDS_Version should match what we defined in /etc/freetds/freetds.conf
[mssql]
Description = MSSQL Server
Driver = freetds
Database = XXXXXX
ServerName = MSSQL
TDS_Version = 8.0
/etc/odbcinst.ini
# Define where to find the driver for the Free TDS connections.
[freetds]
Description = MS SQL database access with Free TDS
Driver = /usr/lib/i386-linux-gnu/odbc/libtdsodbc.so
Setup = /usr/lib/i386-linux-gnu/odbc/libtdsS.so
UsageCount = 1
/etc/freetds/freetds.conf
# The basics for defining a DSN (Data Source Name)
# [data_source_name]
# host = <hostname or IP address>
# port = <port number to connect to - probably 1433>
# tds version = <TDS version to use - probably 8.0>
# Define a connection to the Microsoft SQL Server
[mssql]
host = XXXXXX
port = 1433
tds version = 8.0
And here's the PHP code:
$con = new PDO('dblib:host=mssql;dbname=MyDB', 'domain\username', 'password');
You may need to tweak things a bit for your OS. To install the necessary software on Ubuntu I did something like this:
sudo apt-get install php5-odbc php5-sybase tdsodbc
Use PDO and instal this http://www.php.net/manual/en/ref.pdo-sqlsrv.php
I always use PDO it can easy do all the database interaction you need with different db drivers and the same php code. Except the query languages which is sometimes a little different.
For MSSQL you only need to add the drivers just paste the .dll's, add the entry to the conf.ini and restart apache.
Related
I'm trying to get a PHP 5.3.10 installation on Ubuntu 12.04 to connect to a a remote SQL Anywhere 12 (Sybase?) server using ODBC (unixODBC). However, PHP's execution halts at odbc_connect().
PHP code:
$odbc = odbc_connect('DSN=TP189902;', 'username', 'password');
if ($odbc)
{
echo 'Connected';
}
else
{
echo 'Failed: '.odbc_error($odbc);
}
So regardless of whether or not it connects, it should be outputting one of the echos, but it doesn't. If I try using PHP's PDO library instead, I get the same result.
My unixODBC setup looks like the following. And this might be where my mistake is, because I've never setup ODBC on linux before and am not very familiar with it.
odbcinst.ini
[SQL Anywhere 12]
Description = SQL Anywhere 12
Driver = /opt/sqlanywhere12/lib64/libdbodbc12.so
Setup = /opt/sqlanywhere12/lib64/libdbodbc12.so
odbc.ini
[TP189902]
Description = TP189902
Uid = username
Pwd = password
Driver = SQL Anywhere 12
ServerName = 189902
CommLinks = tcpip(Host=1.2.3.4)
DatabaseName = DB189902
I've also tried a ton of alternatives, such as using the driver's path for the Driver value, using Host=1.2.3.4 instead of CommLinks, etc.
Also the command isql -v TP189902 username password doesn't output anything unless I give it a fake DSN so that it outputs and error.
I've also verified that libdbodbc12.so is the same architecture as isql and that it has all of it's dependencies.
On top of this, I have very similar setup on a Windows 7 machine running WAMP, that connects just fine (with both the ODBC and PDO library). I used the same DSN details on it.
Edit: I've also tried this to skip the DSN, but it gives the same result. It also works on the Windows box.
$odbc = odbc_connect('Driver={SQL Anywhere 12};Server=189902;CommLinks=tcpip(Host=1.2.3.4);', 'username', 'password');
I don't use PHP these days but here are some things I've spotted:
I would totally ignore php until you get isql working.
I'm assuming it is a typo that you say your system ini file is "odbcinstr.ini" - it should be "odbcinst.ini".
How do you know you are looking at the right odbc ini files - run odbcinst -j to check the locations unixODBC is using.
I know where that "[ODBC Data Sources]" section comes from (iodbc) but it not at all necessary for unixODBC - just delete the first 2 lines of your odbc.ini file.
your isql line is probably missing a username and password - it should be "isql -v TP189902 username password". I cannot for the life of me see why it would output nothing at all.
Ultimately the issue was getting the LD_LIBRARY_PATH set to /opt/sqlanywhere12/lib64 for Apache.
Setting it in /etc/environment got isql -v TP189902 and php connect.php working when called from any shell user, but not Apache.
To get Apache to see it, I had to edit /etc/init.d/apache2 and change
ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin"
to
ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/sqlanywhere12/lib64".
And then restart the Apache service.
Various other methods I found online to do this did not work.
One caveat is that with the path set, unixODBC still won't read my system DSN file for some reason. So to get Apache to access the DSN, I had to make a user DSN file (.odbc.ini) in /var/www, as that's the Apache user's (www-data) home folder.
I'm attempting to connect to a SQL Azure database via PHP running on an Ubuntu 11.04 server.
The server is running PHP Version => 5.3.5-1ubuntu7.11.
I've installed freetds-bin, freetds-common, tdsodbc, odbcinst, php5-odbc and unixodbc using apt-get install multiple times. I attempted to compile FreeTDS with SSL support, but am not sure that was successful.
At this point, I receive an error "08S01 - Communication link failure" when attempting to connect using the isql tool. A Microsoft article explains the error as "The communication link between the driver and the data source to which the driver was attempting to connect failed before the SQLDriverConnect function completed processing." Some research on that specifically points to lack of SSL support in FreeTDS, but I'm unclear how to verify that has been enabled.
I will using either PHP Data Objects or mssql_* functions to connect to the SQL Azure database. I'm less familiar with PDO, but it seems that PDO does not necessarily use ODBC? I'm quite unclear on that, and I suspect it's leading me to troubleshoot problems seen by isql that are unrelated to the problems I'm seeing in PHP. Do connectivity problems with the isql tool relate to connectivity problems in either PDO or mssql_* functions in PHP?
My latest attempt, using PDO, is:
<?php
$c = new PDO("odbc:Driver=FreeTDS;Port=1433;Server=sssssssssss.database.windows.net;Database=db_xxxxx_xxx_xxx;UID=db_xxxxx_xxx_xxx_ExternalWriter;PWD=ppppppppp");
?>
This code generates the following errors in my Apache log file:
[Tue Dec 24 13:23:10 2013] [error] [client 10.1.1.11] PHP Fatal error:
Uncaught exception 'PDOException' with message 'SQLSTATE[08S01]
SQLDriverConnect: 20004 [unixODBC][FreeTDS][SQL Server]Read from the
server failed' in /var/www/test/pdo.php:3\nStack trace:\n#0
/var/www/test/pdo.php(3): PDO->__construct('odbc:Driver=Fre...')\n#1
{main}\n thrown in /var/www/test/pdo.php on line 3
My /etc/freetds/freetds.conf:
[global]
# TDS protocol version
tds version = 9.1
# Whether to write a TDSDUMP file for diagnostic purposes
# (setting this to /tmp is insecure on a multi-user system)
dump file = /tmp/freetds.log
debug flags = 0xffff
# Command and connection timeouts
; timeout = 10
; connect timeout = 10
# If you get out-of-memory errors, it may mean that your client
# is trying to allocate a huge buffer for a TEXT field.
# Try setting 'text size' to a more reasonable limit
text size = 64512
# A typical Microsoft server
[FreeTDS]
host = ssssssssss.database.windows.net
port = 1433
tds version = 9.1
client charset = UTF-8
/etc/odbc.ini:
[TS]
Description = "test"
Driver = FreeTDS
Server = sssssssssssss.database.windows.net
Port = 1433
Database = db_xxxxxxx_xxx_xxx
/etc/odbcinst.ini
[FreeTDS]
Description = tdsodbc
Driver = /usr/lib/odbc/libtdsodbc.so
Any help on this mess would be very appreciated. I'm clearly lost at this point. Thanks!
I've not tried it with Azure specifically, but on the local SQL Server machines we have here I found the php5-sybase module with PDO to be massively easier to live with than freetds:
apt-get install php5-sybase
<?php
$dsn = 'dblib:dbname=TestDB;host=sqlserver;charset=UTF-8';
$dbh = new PDO($dsn, 'username', 'password');
Also, when troubleshooting issues, I find looking at Wireshark traces of the DB traffic to be enlightening, as there are often very helpful messages emitted by SQL server that don't make it out in the PDO error.
I'm trying to execute a (very) simple query on Azure MSSql Server using PHP, but it does not work and prints the follow message:
Warning: mssql_query(): message: Invalid object name 'MyTable'.
(severity 16)
I believe that the underlying driver is connecting directly the master database and that's why my objects are not available. So the obvious solution could be mssql_select_db() function, but it raises the follow error message:
Warning: mssql_select_db(): message: USE statement is not supported to
switch between databases. Use a new connection to connect to a
different Database. (severity 16)
So, any of you guys have ever queried successfuly the MS Azure SqlServer using PHP?
Aditional info:
1 - The connection appears to be OK, with no errors.
2 - I can't qualify/prefix my objects with database.schema, otherwise Azure says:
Warning: mssql_query(): message: Reference to database and/or server
name in 'myDatabase.dbo.MyTable' is not supported in this version of
SQL Server. (severity 15)
The General config is:
- CentOS
- PHP 5.3.3
- FreeTDS
- Apache 2
/etc/freetds.conf relevant part is like follows:
[global]
#TDS protocol version
; tds version = 4.2
[MyServerAtAzure]
host = mydatabase.database.windows.net
port = 1433
tds version = 8.0
database = MyDatabase
client_charset = UTF-8
The tsql output's:
# tsql -C
Compile-time settings (established with the "configure" script)
Version: freetds v0.91
freetds.conf directory: /etc
MS db-lib source compatibility: yes
Sybase binary compatibility: yes
Thread safety: yes
iconv library: yes
TDS version: 4.2
iODBC: no
unixodbc: yes
SSPI "trusted" logins: no
Kerberos: yes
And finally, the PHP code:
<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');
# Older FreeTDS installations need the FREETDSCONF Environment variable
putenv('FREETDSCONF=/etc/freetds.conf');
# Current release of FreeTDS uses the FREETDS environment variable. So we set both to be sure
putenv('FREETDS=/etc/freetds.conf');
$link = mssql_connect('MyServerAtAzure', 'user#mydatabase', 'password');
if ( !$link ) die('<br>Oops! CannotConnect');
//mssql_select_db('MyDatabase', $link); # FAILS because you can't use "USE" statement
$sql = "SELECT * FROM dbo.MyTable";
$rs = mssql_query($sql, $link);
?>
The previous resources that I've already visited are:
-
why-is-my-sql-server-query-failing
use-statement-is-not-supported-to-switch-between-databases-when-running-query
PHPFreaks
You can't perform cross-database queries and, like the error message says, you also can't change database context using USE. If you want to query from multiple Azure databases, you need to connect to them independently with different connection strings.
Also, did you try specifying the database explicitly (and not connecting to [...].wondows.net:
[MyServerAtAzure]
host = mydatabase.database.windows.net
port = 1433
Database = myDatabase
tds version = 8.0
client_charset = UTF-8
And also properly prefixing your table with its schema?
$sql = "SELECT * FROM dbo.MyTable;";
I have managed to read data of Microsoft Access file (.accdb) on Windows using PDO but I'm having problem getting to work on Linux (CentOS). I can see modules is installed:
[root#rapid host]# php -m | grep PDO
PDO
PDO_ODBC
[root#rapid host]# php -m | grep odbc
odbc
code:
<?php
try{
$dbhAccess = new PDO("odbc:Driver={Microsoft Access Driver (*.mdb, *.accdb)};Dbq=/root/access/data.accdb;Uid=Admin");
}
catch(PDOException $e){
echo $e->getMessage();
exit();
}
I get an erro when I execute (CLI) PHP file:
[root#rapid host]# php access.php
SQLSTATE[IM002] SQLDriverConnect: 0 [unixODBC][Driver Manager]Data source name not found, and no default driver specified
you should install the MDB driver.
I have no way to try it now, but I think that MDB Tools (specifically the ODBC driver) can do what you' re interested to.
I've never worked with a Microsoft Access database but I do regularly connect to DB2 (on IBM AS/400's) and MS SQL servers from Linux (Ubuntu) servers. Your error seems to indicate you don't have a MS Access driver installed - the only one I'm aware of is: http://www.easysoft.com/products/data_access/odbc-access-driver/index.html
Your error message also says the "Data source name not found" - in order for me to connect to DB2 or MSSQL I have to add some information to /etc/odbc.ini and /etc/odbcinst.ini.
/etc/odbcinst.ini - this is where you describe where to find the drivers for ODBC. Here's an example of what I use for DB2 and MSSQL:
[iseries]
Description = iSeries Access for Linux ODBC Driver
Driver = /usr/lib/libcwbodbc.so
Setup = /usr/lib/libcwbodbcs.so
NOTE1 = If using unixODBC 2.2.11 or later and you want the 32 and 64-bit ODBC drivers to share DSN's,
NOTE2 = the following Driver64/Setup64 keywords will provide that support.
Driver64 = /usr/lib/lib64/libcwbodbc.so
Setup64 = /usr/lib/lib64/libcwbodbcs.so
Threading = 2
DontDLClose = 1
UsageCount = 1
# Define where to find the driver for the Free TDS connections.
[freetds]
Description = MS SQL database access with Free TDS
Driver = /usr/lib/i386-linux-gnu/odbc/libtdsodbc.so
Setup = /usr/lib/i386-linux-gnu/odbc/libtdsS.so
UsageCount = 1
[ODBC]
Trace = no
TraceFile = /tmp/odbc.log
In that last section ([ODBC]) I currently have Trace = no - if you change that to Trace = yes you will get some helpful debugging information in the /tmp/odbc.log file.
/etc/odbc.ini - this is where you define your data sources. Here's an example of what I use for DB2 and MSSQL:
[primary]
Description = primary
Driver = iseries
System = XXX.XXX.XXX.XXX
UserID = XXXXXXXXXX
Password = XXXXXXXXXX
Naming = 0
DefaultLibraries = QGPL
Database = MYLIB
ConnectionType = 0
CommitMode = 2
ExtendedDynamic = 0
DefaultPkgLibrary = QGPL
DefaultPackage = A/DEFAULT(IBM),2,0,1,0,512
AllowDataCompression = 1
LibraryView = 0
AllowUnsupportedChar = 0
ForceTranslation = 0
Trace = 0
# Define a connection to the MSSQL server.
# The Description can be whatever we want it to be.
# The Driver value must match what we have defined in /etc/odbcinst.ini
# The Database name must be the name of the database this connection will connect to.
# The ServerName is the name we defined in /etc/freetds/freetds.conf
# The TDS_Version should match what we defined in /etc/freetds/freetds.conf
[mssql]
Description = MSSQL Server
Driver = freetds
Database = MyDatabase
ServerName = mssql
TDS_Version = 8.0
I've seen a number of questions here on StackOverflow talking about using MSFT Access databases from a Linux machine - and there doesn't seem to ever be a happy ending. If there is any way you can port the data to a different, better supported, database system (like MySQL) I think you'll save yourself some headaches. Good luck!
You can not use {Microsoft Access Driver (*.mdb, *.accdb)} as part of your data source because Microsoft do not make an MS Access ODBC driver for Linux. There are 2 ODBC drivers for MS Access as far as I know of. The MDB Tools and the Easysoft ODBC-Access Driver.
If you install either driver you can either use a DSN which you setup in your odbc.ini file or as you prefer a DSN-Less connection. Here is an example of the an Easysoft DSN-Less connection to an MS Access database
PDO("odbc:Driver={Driver=Easysoft ODBC-ACCESS};Dbq=/root/access/data.accdb");
More information on connecting and getting data back using PDO-ODBC can be found on Easysoft PHP guide There is a section about half way down that talks about PDO-ODBC.
import pandas_access as mdb
db_filename = 'my_db.mdb'
# Listing the tables
for tbl in mdb.list_tables(db_filename):
print(tbl)
# Read a small table
df = mdb.read_table(db_filename, "MyTable")
On Ubuntu you may need to run:
sudo apt install mdbtools
For WINDOWS this is the solution.
After investing a lot of time I have the solution.
The 32-bit version of "AccessDatabaseEngine" must be installed.
Download the 32-bit Access Engine on: https://www.microsoft.com/es-es/download/confirmation.aspx?id=13255
And run it with the command line: AccessDatabaseEngine.exe /passive
After that, it should work.
I'm running php5 on Ubuntu10.10 server where the unixODBC and php5-odbc packages have already been installed. I keep getting an error during the connection process - code:
$data_source = 'DRIVER={Microsoft dBASE Driver (*.dbf)};Data Source=//128.251.xxx.xxx/lv_apps/AppsLON/CData/dbf/cdma';"", "");
$conn = odbc_connect($data_source, "", "");
if (!$conn)
exit("Connection Failed: " .$conn );
error message:
1 Warning: odbc_connect(): SQL error: [unixODBC][Driver Manager]Data source name not found, and no default driver specified, SQL state IM002 in SQLConnect in /var/www/vfptest.php on line 6
I added extention=dbase.so and extention=odbc.so to both files: /etc/php5/apache2/php.ini and /etc/php5/cli/php.ini and re-compiled the php install with:
sudo ./configure --prefix=/usr --enable-dbase=shared --with-unixODBC
I've also gone to unixODBC and pecl to install the unixODBC and dbase libraries separately with no luck.
Also I found this link: http://www.devlist.com/ConnectionStringsPage.aspx
where it is stated that in order to create an ODBC connection to a foxpro database I use the line:
Driver={Microsoft Visual FoxPro Driver};SourceType=DBC;SourceDB=c:\demo.dbc;Exclusive=No;NULL=NO;Collate=Machine;BACKGROUNDFETCH=NO;DELETED=NO
this still did not work for me however; probably because I do not have the visual foxpro driver installed or my odbc.ini file pointing to the driver path...but I don't know.
In short - odbc_connect() takes; an ODBC Data Source Name (DSN), Username & Password as per --
http://php.net/manual/en/function.odbc-connect.php
As far as I am aware there is no VFP ODBC driver for Linux so you will, most likely, need to employ an ODBC Bridge solution like -
http://uda.openlinksw.com/odbc-odbc-mt/
This has a client/server architecture --
Linux client --
php ODBC Application
OpenLink Generic ODBC Driver (thin multi-tier ODBC client)
Windows server --
OpenLink Request Broker (Multi-tier server)
OpenLInk Agent for ODBC (Multi-tier server)
Fox Pro ODBC DSN (pre configured)
Fox Pro files...
I hope this helps?
Check out the very bottom of this thread on the MSDN network
the driver line you have posted is "...an ODBC connection string which is not supported for VFP tables having a version later than 6."
Although not familiar with linux connecting to VFP, however, odbc connections for such VFP connect to a PATH, not a specific table. Once the connection to the PATH is valid, THEN you can query any .DBF table IN that location.
Although I can't answer your specific connection info, I've found this link
http://www.phpfreaks.com/forums/index.php?topic=296832.0
that shows connecting to a datasource... notice its identifying the 'DRIVER={Microsoft dBASE Driver (*.dbf)};datasource=/home/dir/file.dbf;' used... You'll probably have to hit a combination of this driver and pathing info (I'd still try WITHOUT the specific .dbf file first).
Hope this helps..