I'm trying to install the SQL Anywhere interface for PHP on Centos (=RHEL)
Linux 5.1, x86_64, which uses PHP 5.1.6. I tried using the prebuilt module
for PHP 5.1.2 but it didn't do anything. My next step was to try building
just the sqlanywhere.so module, using the instructions that were posted to
this group on 2007-02-01. Following that procedure, I was able to run "php
connect.php" successfully from the command line, but the connection failed
when I tried serving connect.php with the Apache server (httpd 2.2.3). (Yes,
I sourced sa_config.sh in the shell that ran httpd).

So I decided I would give up on the shortcuts and follow the long procedure
Sybase documents on its website for adding the SQL Anywhere module to the
PHP source tree. Unfortunately, I had to remove my distro's PHP installation
to do this. I couldn't use the PHP source from my distro, because the
distro's php-devel package does not have the buildconf file that the SQL
Anywhere documentation calls for. When I eventually got done building and
installing my custom PHP version, which my distro can't update, it was so
unconfigured that .php files were served as raw code, without being
interpreted by Apache. At present, Apache is down and I can't get it started
again.

There really should be a documented way to build the SQL Anywhere module for
PHP without rebuilding (messily) PHP itself. At this point, I plan to go
back to my distro's version of PHP, and I seem to face a choice of either
SQL Anywhere and ODBC middleware or a different database with a working PHP
module. But before that, does anyone have any tips for getting the SQL
Anywhere module working?

Richard

I'm aware that building the PHP module is troublesome. To quote Jason
Hinsperger from the general newsgroup: "[We] are currently working on a
way to better support php developers without having to build a new
driver every time a new version of PHP is released." Unfortunately, the
way PHP is designed makes it difficult to avoid a lot of this trouble
(most of their interfaces are implemented as macros).

Are you running 64-bit or 32-bit PHP/Apache? Make sure your PHP driver
matches the bitness of PHP/Apache.

You were able to connect at one point using the CGI PHP interpreter
(command line). So, that tells me everything was working from a PHP
standpoint. What do you mean by "the connection failed" when using
Apache/mod_php? Did the library fail to load? Was it able to load the
library but the connection to the database failed?

If it loaded the library but could not connect, did you try connecting
over TCP/IP? The most likely scenario that I'm thinking of right now is
that Apache is running as a different user than SQL Anywhere (which
version of SA are you using?) and either cannot find or does not have
permission to use the shared memory link.

Try TCP/IP. If that works, but you'd rather still use shared memory,
there are a couple of things you can try. Make sure your SATMP (or
ASTMP in 9.0, or just TMP if neither of those is set) are set the same
for both SA and Apache. Then check the file permissions (including the
containing directories) to ensure that the user under which Apache is
running will be able to access it.

You might be able to find something in the Apache logs that indicates
the reason for the failure to connect. Of course, if you are running
with SELinux enabled, you'll have to ensure that you are not getting AVC
denials.

Let me know if you need clarification/further assistance.

Thanks,
Phil

Richard Biffl wrote:

I'm aware that building the PHP module is troublesome. To quote Jason
Hinsperger from the general newsgroup: "[We] are currently working on a
way to better support php developers without having to build a new
driver every time a new version of PHP is released." Unfortunately, the
way PHP is designed makes it difficult to avoid a lot of this trouble
(most of their interfaces are implemented as macros).

Are you running 64-bit or 32-bit PHP/Apache? Make sure your PHP driver
matches the bitness of PHP/Apache.

You were able to connect at one point using the CGI PHP interpreter
(command line). So, that tells me everything was working from a PHP
standpoint. What do you mean by "the connection failed" when using
Apache/mod_php? Did the library fail to load? Was it able to load the
library but the connection to the database failed?

If it loaded the library but could not connect, did you try connecting
over TCP/IP? The most likely scenario that I'm thinking of right now is
that Apache is running as a different user than SQL Anywhere (which
version of SA are you using?) and either cannot find or does not have
permission to use the shared memory link.

Try TCP/IP. If that works, but you'd rather still use shared memory,
there are a couple of things you can try. Make sure your SATMP (or
ASTMP in 9.0, or just TMP if neither of those is set) are set the same
for both SA and Apache. Then check the file permissions (including the
containing directories) to ensure that the user under which Apache is
running will be able to access it.

You might be able to find something in the Apache logs that indicates
the reason for the failure to connect. Of course, if you are running
with SELinux enabled, you'll have to ensure that you are not getting AVC
denials.

Let me know if you need clarification/further assistance.

Thanks,
Phil

Richard Biffl wrote:

I'm aware that building the PHP module is troublesome. To quote Jason
Hinsperger from the general newsgroup: "[We] are currently working on a
way to better support php developers without having to build a new
driver every time a new version of PHP is released." Unfortunately, the
way PHP is designed makes it difficult to avoid a lot of this trouble
(most of their interfaces are implemented as macros).

Are you running 64-bit or 32-bit PHP/Apache? Make sure your PHP driver
matches the bitness of PHP/Apache.

You were able to connect at one point using the CGI PHP interpreter
(command line). So, that tells me everything was working from a PHP
standpoint. What do you mean by "the connection failed" when using
Apache/mod_php? Did the library fail to load? Was it able to load the
library but the connection to the database failed?

If it loaded the library but could not connect, did you try connecting
over TCP/IP? The most likely scenario that I'm thinking of right now is
that Apache is running as a different user than SQL Anywhere (which
version of SA are you using?) and either cannot find or does not have
permission to use the shared memory link.

Try TCP/IP. If that works, but you'd rather still use shared memory,
there are a couple of things you can try. Make sure your SATMP (or
ASTMP in 9.0, or just TMP if neither of those is set) are set the same
for both SA and Apache. Then check the file permissions (including the
containing directories) to ensure that the user under which Apache is
running will be able to access it.

You might be able to find something in the Apache logs that indicates
the reason for the failure to connect. Of course, if you are running
with SELinux enabled, you'll have to ensure that you are not getting AVC
denials.

Let me know if you need clarification/further assistance.

Thanks,
Phil

Richard Biffl wrote:

I'm aware that building the PHP module is troublesome. To quote Jason
Hinsperger from the general newsgroup: "[We] are currently working on a
way to better support php developers without having to build a new
driver every time a new version of PHP is released." Unfortunately, the
way PHP is designed makes it difficult to avoid a lot of this trouble
(most of their interfaces are implemented as macros).

Are you running 64-bit or 32-bit PHP/Apache? Make sure your PHP driver
matches the bitness of PHP/Apache.

You were able to connect at one point using the CGI PHP interpreter
(command line). So, that tells me everything was working from a PHP
standpoint. What do you mean by "the connection failed" when using
Apache/mod_php? Did the library fail to load? Was it able to load the
library but the connection to the database failed?

If it loaded the library but could not connect, did you try connecting
over TCP/IP? The most likely scenario that I'm thinking of right now is
that Apache is running as a different user than SQL Anywhere (which
version of SA are you using?) and either cannot find or does not have
permission to use the shared memory link.

Try TCP/IP. If that works, but you'd rather still use shared memory,
there are a couple of things you can try. Make sure your SATMP (or
ASTMP in 9.0, or just TMP if neither of those is set) are set the same
for both SA and Apache. Then check the file permissions (including the
containing directories) to ensure that the user under which Apache is
running will be able to access it.

You might be able to find something in the Apache logs that indicates
the reason for the failure to connect. Of course, if you are running
with SELinux enabled, you'll have to ensure that you are not getting AVC
denials.

Let me know if you need clarification/further assistance.

Thanks,
Phil

Richard Biffl wrote:

I'm aware that building the PHP module is troublesome. To quote Jason
Hinsperger from the general newsgroup: "[We] are currently working on a
way to better support php developers without having to build a new
driver every time a new version of PHP is released." Unfortunately, the
way PHP is designed makes it difficult to avoid a lot of this trouble
(most of their interfaces are implemented as macros).

Are you running 64-bit or 32-bit PHP/Apache? Make sure your PHP driver
matches the bitness of PHP/Apache.

You were able to connect at one point using the CGI PHP interpreter
(command line). So, that tells me everything was working from a PHP
standpoint. What do you mean by "the connection failed" when using
Apache/mod_php? Did the library fail to load? Was it able to load the
library but the connection to the database failed?

If it loaded the library but could not connect, did you try connecting
over TCP/IP? The most likely scenario that I'm thinking of right now is
that Apache is running as a different user than SQL Anywhere (which
version of SA are you using?) and either cannot find or does not have
permission to use the shared memory link.

Try TCP/IP. If that works, but you'd rather still use shared memory,
there are a couple of things you can try. Make sure your SATMP (or
ASTMP in 9.0, or just TMP if neither of those is set) are set the same
for both SA and Apache. Then check the file permissions (including the
containing directories) to ensure that the user under which Apache is
running will be able to access it.

You might be able to find something in the Apache logs that indicates
the reason for the failure to connect. Of course, if you are running
with SELinux enabled, you'll have to ensure that you are not getting AVC
denials.

Let me know if you need clarification/further assistance.

Thanks,
Phil

Richard Biffl wrote:

I'm aware that building the PHP module is troublesome. To quote Jason
Hinsperger from the general newsgroup: "[We] are currently working on a
way to better support php developers without having to build a new
driver every time a new version of PHP is released." Unfortunately, the
way PHP is designed makes it difficult to avoid a lot of this trouble
(most of their interfaces are implemented as macros).

Are you running 64-bit or 32-bit PHP/Apache? Make sure your PHP driver
matches the bitness of PHP/Apache.

You were able to connect at one point using the CGI PHP interpreter
(command line). So, that tells me everything was working from a PHP
standpoint. What do you mean by "the connection failed" when using
Apache/mod_php? Did the library fail to load? Was it able to load the
library but the connection to the database failed?

If it loaded the library but could not connect, did you try connecting
over TCP/IP? The most likely scenario that I'm thinking of right now is
that Apache is running as a different user than SQL Anywhere (which
version of SA are you using?) and either cannot find or does not have
permission to use the shared memory link.

Try TCP/IP. If that works, but you'd rather still use shared memory,
there are a couple of things you can try. Make sure your SATMP (or
ASTMP in 9.0, or just TMP if neither of those is set) are set the same
for both SA and Apache. Then check the file permissions (including the
containing directories) to ensure that the user under which Apache is
running will be able to access it.

You might be able to find something in the Apache logs that indicates
the reason for the failure to connect. Of course, if you are running
with SELinux enabled, you'll have to ensure that you are not getting AVC
denials.

Let me know if you need clarification/further assistance.

Thanks,
Phil

Richard Biffl wrote:

I'm aware that building the PHP module is troublesome. To quote Jason
Hinsperger from the general newsgroup: "[We] are currently working on a
way to better support php developers without having to build a new
driver every time a new version of PHP is released." Unfortunately, the
way PHP is designed makes it difficult to avoid a lot of this trouble
(most of their interfaces are implemented as macros).

Are you running 64-bit or 32-bit PHP/Apache? Make sure your PHP driver
matches the bitness of PHP/Apache.

You were able to connect at one point using the CGI PHP interpreter
(command line). So, that tells me everything was working from a PHP
standpoint. What do you mean by "the connection failed" when using
Apache/mod_php? Did the library fail to load? Was it able to load the
library but the connection to the database failed?

If it loaded the library but could not connect, did you try connecting
over TCP/IP? The most likely scenario that I'm thinking of right now is
that Apache is running as a different user than SQL Anywhere (which
version of SA are you using?) and either cannot find or does not have
permission to use the shared memory link.

Try TCP/IP. If that works, but you'd rather still use shared memory,
there are a couple of things you can try. Make sure your SATMP (or
ASTMP in 9.0, or just TMP if neither of those is set) are set the same
for both SA and Apache. Then check the file permissions (including the
containing directories) to ensure that the user under which Apache is
running will be able to access it.

You might be able to find something in the Apache logs that indicates
the reason for the failure to connect. Of course, if you are running
with SELinux enabled, you'll have to ensure that you are not getting AVC
denials.

Let me know if you need clarification/further assistance.

Thanks,
Phil

Richard Biffl wrote:

I'm aware that building the PHP module is troublesome. To quote Jason
Hinsperger from the general newsgroup: "[We] are currently working on a
way to better support php developers without having to build a new
driver every time a new version of PHP is released." Unfortunately, the
way PHP is designed makes it difficult to avoid a lot of this trouble
(most of their interfaces are implemented as macros).

Are you running 64-bit or 32-bit PHP/Apache? Make sure your PHP driver
matches the bitness of PHP/Apache.

You were able to connect at one point using the CGI PHP interpreter
(command line). So, that tells me everything was working from a PHP
standpoint. What do you mean by "the connection failed" when using
Apache/mod_php? Did the library fail to load? Was it able to load the
library but the connection to the database failed?

If it loaded the library but could not connect, did you try connecting
over TCP/IP? The most likely scenario that I'm thinking of right now is
that Apache is running as a different user than SQL Anywhere (which
version of SA are you using?) and either cannot find or does not have
permission to use the shared memory link.

Try TCP/IP. If that works, but you'd rather still use shared memory,
there are a couple of things you can try. Make sure your SATMP (or
ASTMP in 9.0, or just TMP if neither of those is set) are set the same
for both SA and Apache. Then check the file permissions (including the
containing directories) to ensure that the user under which Apache is
running will be able to access it.

You might be able to find something in the Apache logs that indicates
the reason for the failure to connect. Of course, if you are running
with SELinux enabled, you'll have to ensure that you are not getting AVC
denials.

Let me know if you need clarification/further assistance.

Thanks,
Phil

Richard Biffl wrote:

I'm aware that building the PHP module is troublesome. To quote Jason
Hinsperger from the general newsgroup: "[We] are currently working on a
way to better support php developers without having to build a new
driver every time a new version of PHP is released." Unfortunately, the
way PHP is designed makes it difficult to avoid a lot of this trouble
(most of their interfaces are implemented as macros).

Are you running 64-bit or 32-bit PHP/Apache? Make sure your PHP driver
matches the bitness of PHP/Apache.

You were able to connect at one point using the CGI PHP interpreter
(command line). So, that tells me everything was working from a PHP
standpoint. What do you mean by "the connection failed" when using
Apache/mod_php? Did the library fail to load? Was it able to load the
library but the connection to the database failed?

If it loaded the library but could not connect, did you try connecting
over TCP/IP? The most likely scenario that I'm thinking of right now is
that Apache is running as a different user than SQL Anywhere (which
version of SA are you using?) and either cannot find or does not have
permission to use the shared memory link.

Try TCP/IP. If that works, but you'd rather still use shared memory,
there are a couple of things you can try. Make sure your SATMP (or
ASTMP in 9.0, or just TMP if neither of those is set) are set the same
for both SA and Apache. Then check the file permissions (including the
containing directories) to ensure that the user under which Apache is
running will be able to access it.

You might be able to find something in the Apache logs that indicates
the reason for the failure to connect. Of course, if you are running
with SELinux enabled, you'll have to ensure that you are not getting AVC
denials.

Let me know if you need clarification/further assistance.

Thanks,
Phil

Richard Biffl wrote: