|
From: Bert A. <ba_...@ya...> - 2009-06-09 13:04:34
|
Hello Ted,
I think you got really close with your last hint - that PHP either can't find odbc(inst).ini, or that it can't link/load iODBC properly.
I managed to connect in 3 independent ways to the MySQL database :
1) using iodbctest, applying the connect string "DSN=THUIS;user=root;password=secret_pwd"
2) using OpenOffice Base connecting to a database through ODBC
3) using ODBC Administrator TEST button
( You're right that the Mac ODBC Administrator itsself doesn't have a test button - but if you add/configure a system DSN, you get a form holding the MySQL logo that does have a test button. I couldn't see a link to a *.dmg file you sent along, otherwise I would've tested that too )
Three times, the trace file (configured in the DSN ) was updated with correct time stamps, identifiers of the calling program, and nothing but SQL_SUCCESS return codes. No problem to be found here.
I slightly modified my PHP script for the remainder of the tests :
=== top of connect.php =================
<?php // connect to database
//$dsn = "DSN=THUIS;user=root;password=secret_pwd" ;
$dsn="THUIS" ;
$usr = "root" ;
$pwd = "l!efsteLau" ;
$retCode = 1 ;
$cnx = odbc_connect( $dsn, $usr, $pwd ) or $retCode = 0;
if ( $retCode > 1 )
echo "resource ID = -->$cnx<-- ! " ;
else
echo "Could not connect to ODBC source '$dsn' with '$usr', pwd '$pwd' ";
echo "<P><B>env(ODBCINI) is : ==>'" . getenv('ODBCINI') . "'<== before<BR></B>" ;
echo "<B>env(ODBCINSTINI) is : ==>'" . getenv('ODBCINSTINI') . "'<== before</B></P>" ;
putenv("ODBCINSTINI=/Library/ODBC/odbcinst.ini");
putenv("ODBCINI=/Library/ODBC/odbc.ini");
echo "<P><B>env(ODBCINI) is : ==>'" . getenv('ODBCINI') . "'<== after<BR></B>" ;
echo "<B>env(ODBCINSTINI) is : ==>'" . getenv('ODBCINSTINI') . "'<== after</B></P>" ;
$retCode = 1 ;
$cnx = odbc_connect( $dsn, $usr, $pwd ) or $retCode = 0;
if ( $retCode > 1 )
echo "resource ID = -->$cnx<-- ! " ;
else
echo "Could not connect to ODBC source '$dsn' with '$usr', pwd '$pwd' ";
phpinfo() ;
?>
=== bottom of connect.php ==============
Results :
1. the error code is always the same before & after the definition of ODBCINI and OBCINSTINI, regardless of $dsn
2. $dsn = "THUIS" ( = reference to system DSN defined in odbc.ini+odbcinst.ini) : error code IM003
3. $dsn = "DSN=THUIS;user=root;password=secret_pwd" ( = as successfully used in iodbctest): error code IM002
4. in cases 2) and 3), the trace file wasn't touched: it remains as it was
5. the error message (also in system log, /Applications/Utilities/Console) says "Warning: ... SQL error: [iODBC][Driver Manager]Specified driver could not be loaded, ... "
>From this, I would deduct that
- PHP can find the odbc.ini: he get's further with the DSN name than with the other definition
- PHP can connect to the driver manager
- but PHP can't get to the driver like the three test app's- if there was the slightest of contact, the trace file would be updated
I don't know too much about the low-level way-of-work of these pieces of software, so let me know if I'm totally off track.
Anyway, in anticipation of a problem with PHP, I took another look at the php.ini file.
Snippet of php.ini :
=== top of php.ini =====================
...
; Directory in which the loadable extensions (modules) reside.
extension_dir = "./"
;extension_dir = "/usr/local/lib/"
;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;
;
; If you wish to have an extension loaded automatically, use the following
; syntax:
;
; extension=modulename.extension
;
; ... or under UNIX:
;
; extension=msql.so
;
; Note that it should be the name of the module only; no directory information
; needs to go here. Specify the location of the extension with the
; extension_dir directive above.
; Windows Extensions
; Note that ODBC support is built in, so no dll is needed for it.
; Note that many DLL files are located in the extensions/ (PHP 4) ext/ (PHP 5)
; extension folders as well as the separate PECL DLL download (PHP 5).
; Be sure to appropriately set the extension_dir directive.
....
;extension=php_zip.dll
extension=libmyodbc5.so
....
=== bottom of php.ini ==================
I've tried setting the directive extension_dir o the directory where libmyodbc5.so resides, and explicitly loaded it.
After an Apache restart ( PHP, as Apache module, only reads php.ini on web server start), the system log gave these messages (so apparently it failed) :
[Tue Jun 09 13:30:30 2009] [notice] caught SIGTERM, shutting down
[Tue Jun 09 13:30:31 2009] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
<br />
<b>Warning</b>: PHP Startup: Unable to load dynamic library '/usr/local/lib/libmyodbc5.so' - (null) in <b>Unknown</b> on line <b>0</b><br />
[Tue Jun 09 13:30:31 2009] [notice] Digest: generating secret for digest authentication ...
[Tue Jun 09 13:30:31 2009] [notice] Digest: done
[Tue Jun 09 13:30:31 2009] [notice] Apache/2.2.8 (Unix) mod_ssl/2.2.8 OpenSSL/0.9.7l DAV/2 PHP/5.2.6 configured -- resuming normal operations
Is this in line with your expectations ?
If you have another great hint to get me afloat again - I'm all ears !
Kind regards,
Bert
=====\____/======================================
\@@/
\/ "Bert" by name,
Bert Aerts "Bird" by nature
+32(11)48.49.06
=================================================
--- On Thu, 6/4/09, Ted Thibodeau Jr <tth...@op...> wrote:
From: Ted Thibodeau Jr <tth...@op...>
Subject: Re: [Iodbc-macosx] OSX 1.5: ODBC-error IM002 or IM003 using Apache, PHP
To: "Bert Aerts" <ba_...@ya...>
Cc: iod...@li...
Date: Thursday, June 4, 2009, 3:44 AM
Hi, Bert --
Everything you've provided to date suggests that
1. PHP is not finding the odbcinst.ini and/or odbc.ini file,
or
2. PHP is not linked to and/or loading iODBC properly
What I'm trying to lead you through --
1. Configure a DSN which tests successfully using the driver setup
and/or driver manager dialogs. Apple's "ODBC Administrator.app"
has no TEST button, so I provided download links which would
get you the "OpenLink ODBC Administrator.app" which *DOES* have
a TEST button.
2. Test that same DSN with iODBC Test.app, iodbctest, or other
simple application built more natively for Mac OS X than PHP.
Again, these tools are included in the .dmg downloads I linked
previously.
3. Test PHP against the now known-functional DSN.
By proceeding through these three steps in order, we narrow down
and resolve each problem area, and move most swiftly from failure
to success.
On Jun 2, 2009, at 07:07 PM, Bert Aerts wrote:
> I've tried your suggestions, and here are the results :
>
> First suggestion: the stray odbc.ini files : I found none, other
> than those you mentioned that had to be in place. I tried the
> commands find / -name odbc*.ini -print 2> /users/bertaerts/err.txt
> and find / -name .odbc*.ini -print 2> /users/bertaerts/err.txt
> (redirects just to get nuisance warning from stderr out of my
> view), and all they showed was:
> /Library/ODBC/odbc.ini
> /Library/ODBC/odbcinst.ini
> /Users/bertaerts/Library/ODBC/odbc.ini
> /Users/bertaerts/Library/ODBC/odbcinst.ini
So far, so good. It may be necessary to review the full content
of these files. Please send them directly to me (or put on a
temporary FTP or similar download site), rather than sending to
all list members.
> I checked the directories you suggested (I assumed the tilde is
> my user directory, so /Users/bertaerts) :
> ls -alpG /Users/bertaerts -> yields no .odbc.ini, nor .odbcinst.ini
> ls -alpG /etc -> /etc is a symbolic link for /private/etc
> ls -alpG /private/etc -> no odbc.ini, no .odbc.ini, only a PHP.INI.
> (For info, I checked the PHP.INI, only reference to ODBC is an active
> (un-commented) line "extension=php_pdo_odbc.dll" - which, given the
> extension, is no factor on a Mac.)
Yes, the tilde stands for your user directory, and is understood by
the Mac's shell. `ls -alpG ~` would have worked as well as your
first command, above.
Output is as desired.
It may be worth reviewing the php.ini content -- not just about ODBC
as such, but also about dynamic library locations and other general
settings which play a role in the ODBC environment. The full output
of the phpinfo() can also be useful in this analysis.
> Secondly, the iodbctest app. I looked up the web manual for MySQL
> ODBC 5.1 Connector at
> <http://dev.mysql.com/doc/refman/5.1/en/connector-odbc-configuration-connection-parameters.html>,
> and got iodbctest to work :
>
> iODBC Demonstration program
> This program shows an interactive SQL processor
> Driver Manager: 03.52.0406.1211
>
> Enter ODBC connect string (? shows list): ?
>
> DSN | Driver
> ------------------------------------------------------------------------------
> THUIS | MySQL ODBC 5.1 Driver
>
> Enter ODBC connect string (? shows list):user=root;password=
> secret_pwd;database=thuis
> 1: SQLDriverConnect = [iODBC][Driver Manager]Data source name not
> found and no default driver specified. Driver could not be loaded
> (0) SQLSTATE=IM002
> 1: ODBC_Connect = [iODBC][Driver Manager]Data source name not
> found and no default driver specified. Driver could not be loaded
> (0) SQLSTATE=IM002
This failure is not surprising -- you specified no DSN= in your
connect string, so there was no "Data source name" to be found...
> Have a nice day.bert-aertss-macbook-pro:bin bertaerts$ iodbctest
> iODBC Demonstration program
> This program shows an interactive SQL processor
> Driver Manager: 03.52.0406.1211
>
> Enter ODBC connect string (? shows list): driver=MySQL ODBC 5.1
> Driver;database=thuis;server=localhost;user=root;password=secret_pwd
> Driver: 05.01.0005 (libmyodbc5.so)
This is a "DSNless connect string" -- you have entirely bypassed
the odbc.ini file.
However, by specfying the driver by name (not by file location),
you did use the odbcinst.ini file, and proved that the driver,
driver manager, and odbcinst.ini file are all working as desired.
You've also confirmed the minimum set of attributes needed for a
good DSN with that driver.
> SQL>show tables;
>
> Tables_in_thuis
> <lis of my tables>
>
> Logically, I immediately pasted this "DSN"-like definition in my
> connect script - and this failed ...
That doesn't surprise me.
> This time, I noticed again something different from last attempts.
> Before starting the MySQL Server, I executed the following
> statements:
> bertaerts$ export ODBCINI=/Library/ODBC/odbc.ini
> bertaerts$ export ODBCSYSINI=/Library/ODBC
Once again -- ODBCINSTINI was left unset. This is KEY to making
a DSN-based connection, and to making any connection in which the
driver is specified by name ("MySQL ODBC 5.1 Driver") rather than
path ("/Library/ODBC/...")
The ODBCSYSINI environment variable is specific to unixODBC, which
plays no role on Mac OS X, unless you've installed it yourself --
not generally recommended, for a great many reasons. ODBCSYSINI
may therefor be left unset.
> bert-aertss-macbook-pro:~ bertaerts$ cd /usr/local/mysql/bin
> bert-aertss-macbook-pro:bin bertaerts$ ./mysqld_safe
> (i.a.w. <http://dev.mysql.com/doc/refman/5.1/en/connector-odbc-configuration-dsn-unix.html> .
> I tried it, because one of your focal points was the default
> location of an odbc(inst).ini file)
For Mac OS X, the relevant Connector/ODBC documentation is here --
<http://dev.mysql.com/doc/refman/5.1/en/connector-odbc-configuration-dsn-macosx.html>
> The odbc_connect( ) calls using the DSN failed with IM003, those
> with "driver=...;database=...;" failed with IM002.
>
> This is a snippet from the script return to illustrate:
>
> Warning: odbc_connect() [function.odbc-connect]: SQL error:
> [iODBC][Driver Manager]Specified driver could not be loaded,
> SQL state IM003 in SQLConnect in /Users/bertaerts/Documents/
> Apache-PHP/DB_thuis/connect.php on line 26
>
> Could not connect to ODBC source 'thuis' with 'root', pwd
> 'secret_pwd'
>
> Warning: odbc_connect() [function.odbc-connect]: SQL error:
> [iODBC][Driver Manager]Data source name not found and no default
> driver specified. Driver could not be loaded, SQL state IM002 in
> SQLConnect in /Users/bertaerts/Documents/Apache-PHP/DB_thuis/
> connect.php on line 32
>
> Could not connect to ODBC source 'DRIVER={MySQL ODBC 5.1 Driver};
> DATABASE=thuis;SERVER=localhost' with '', pwd ''
>
> I hope this sheds a new light ?
The PHP ODBC connect calls don't make allowance for DSNless connect
strings (unless there's been a recent change); they require that you
pass the DSN, UID, and PWD, as you initially attempted.
Regards,
Ted
|