|
Update: Solution My original intention was to be able to connect php version 5.6.5 to SQL ASA 12 or 16 database. In testing using the DocCommentXchange documentation to test this resulted in my original question. (See Below) PHP would not connect returning an error of driver not found. So I followed the advise in suggestions placing the SQLAnywhere 5.6.0 dll (Which I didn't have originally, only an older version) into the php\ext\ folder ensuring that all appropriate files were in the path. This did not solve the issue. To get it to connect, all I did was to enable the odbc driver in the php.ini file "Dynamic Extensions" section extension=php_pdo_odbc.dll. I then used this connection code in my php web page: $pdo = new PDO("odbc:Driver={SQL Anywhere 16};Host={$host};Server={$servername};Database={$dbname};Uid={$username};Pwd={$pw}"); Original question: I am attempting to connect SQL Anywhere 16 to php but am getting an error that couldn't load dynamic library. I have followed the instructions as per the SAP DocCommentXchange on php extensions, and am now trying the testing php extension as per the DocCommentXchange.
My Apache service is a 64Bit version. Is the error a result of the 32Bit php exetensions being used? If so is there a 64bit version of the extension? Or do I have to use the 32Bit version of Apache? Response to a question: Hi Volker. Yes the folder is in the path. I have just installed 32 Bit Apache and Sybase ASA 16 onto another virtual server. Followed all the same procedures but now get a slightly different message. Appears to be version differences between Sybase php-5.4.12 and php version 5.6.5
|
|
See update to original question. IMHO, it's nothing wrong with leaving the original question unchanged and add your solution as answer - even if you have decided to take a different approach...
(12 Aug '15, 00:46)
Volker Barth
|
AFAIK, on Windows the PHP extension is only available for 32-bit, i.e. the required files are in the bin32 subfolder.
Have you checked that that folder is in your PATH?
Hi Volker.
Yes the folder is in the path.
I have just installed 32 Bit Apache and Sybase ASA 16 onto another virtual server. Followed all the same procedures but now get a slightly different message. Appears to be version differences between Sybase php-5.4.12 and php version 5.6.5
I added the image to the original question for you to see.
Regards
There should not be a version mismatch - to cite from the docs:
So I'd suggest to try a PHP 5.6 driver as available from here:
The SAP SQL Anywhere PHP Module.
(FWIW, current SA 12.0.1 and 16.0.0 builds seem to include only prebuilt PHP modules for 5.4 and below...)
Thanks Volker. I have added the 5.6 drivers, but now get a "Could not open input file: test.php"
Your comment regarding SA 16 builds seem to include modules 5.4, does this mean I should try with SA 17 instead?
Sorry, I can't help further as I have not myself used PHP with SQL Anywhere 16/17.
FWIW, my v17 install (default Developer Edition) does not include any php-xyz_sqlanywhere.dll files, so a change to v17 may not help as desired. The "What's New" doc topics do not state that anything has changed w.r.t. PHP dll delivery, so I'm not sure whether these files are simply missing in the setup or whether one is expected to load the required version from the cited web resource... - I just don't know.
Does it matter that I have the developer version?
I don't think so. The Developer Edition does contain (almost) all features (as can be seen here), including the whole programming language support. - That's what developers need, isn't it? :)
FWIW, when reading about the brand new 16.0.0.2158 EBF, I noticed the following CR 785851 change, as documented here - and fixed in 16.0.0.2146 and apparently contained in v17 GA (though that build number 1062 is smaller than the one cited here):
SQL Anywhere installations no longer include PHP drivers. They are now posted to a web page, but the versions posted only include the .0 release of each major/minor version. The PHP external environment attempts to load the external environment DLL that matches the current phpversion(), which includes the release number. Unless the release number is 0, or an appropriate driver was previously installed, the correct driver will not be found and the PHP external environment will fail to start. This has been fixed. If a DLL with the full version number is available, it will be used. Otherwise the DLL with the .0 release number will be used. e.g. PHP 5.6.5 would use the 5.6.0 DLL. SQLA 12.0.1 and 16.0.0 should continue to work as before, but the fix was included to allow for possible future changes. Workarounds include (one of): - rename the SQLA PHP modules to a name that will be found - set up a php.ini file containing the “extension” setting that will load the SQLA PHP modules - compile the PHP drivers in the SDK directory to match your PHP installationWhats interesting, is now that I have the 5.6.0 dll for Sybase, both 32bit and 64 bit. My original issue of "not a valid Win32 application" arises for the 32bit dll. With the 64 bit dll, I get "Can't load".
Will give the workaround a go
Where can I get the latest developer version with build 2146. The one I downloaded from SAP is 2043
AFAIK there is only one Developer Edition download file for V16... there may be 10,000 paths to get you there, through the mess that is sap.com, but there's only one file, and it gets updated from time to time.
So, keep trying :)
Or, you can buy a copy for CAD 960 and download an EBF. See this page for simple instructions.
Two points based on this comment: - This fix is for the PHP external environment only. It does not affect the PHP API driver like you would use from Apache. - This fix is included in v17 GA build 1063, which is what will be released at some time in the future for platforms other than Linux and Windows. The fix for Linux and Windows will be in the cited patch release.
I think you are on the right track. You need to have the php-5.6.0 driver from the web site in order to use php 5.6.5. You can also compile for yourself, though this is a painful process on Windows.
"Could not open input file: test.php" seems like a different issue.
Just to understand: If this does only relate to the PHP external env., why does the v17 Windows GA not include any php_*.dll files? - I'm quite sure I haven't opted them outduring the setup...
Sorry, the background information provided in the first paragraph applies generally, but the CR itself applies only to the external environment. I'm not sure what sort of announcement was made for the installation change as I was not involved in that part of things.
I have resorted to using ODBC driver to connect successfully. Thanks for all your input
Other people would benefit from knowing how you did that.
...as in "Be the first one to answer this question!" :)