HOWTO: FreeTDS for Newbies (almost complete)

You may want to connect Linux/PHP to a remote MS SQL Server
eventually. One way to do that is to install FreeTDS, recompile PHP,
and then use the mssql_* API within PHP. That API is well documented
on php.net.

Note that my instructions here cover PHP 4.2.2 that ships with RH9. If
you have an earlier or later version, this might not synchronize 100%.
Also note on my RH9 system that I installed EVERYTHING in the
Add/Remove Programs because that's my preference.

So what is FreeTDS? Well, TDS (Tads, you might say) is the native MS
SQL Server protocol served up on port 1433. FreeTDS is a free API for
*nix to connect you to that.

You can go to freetds.org and install the RPMs on Unix or Linux
(*nix). This will create an executable called tsql, which you can use
to verify whether this was installed properly or not.

Let's start using that testing tool:

tsql -S ip.ip.ip.ip -H windows01 -p 1433 -U sa -P ''

This connects to ip address "ip.ip.ip.ip", server named "windows01",
port 1433
(the default port for mssql), user "sa", and no password (specified
with two
tick marks). If I had a password, I'd replace the two tick marks with
the
password.

If you're firewall and net configuration is set up correctly, and
FreeTDS is installed properly, you'll see something like:

1>

What the heck is that? That's similar to an old Oracle command line
interface I once saw. It gives you numbers for every line you type up
until you type GO. Then it starts over again. So, type this:

use pubs
go
select * from authors
go
quit

You'll see a table of authors from the MS SQL Server's pubs database.

That proves that your Linux system has FreeTDS configured correctly.
Now you just need to get PHP to talk to it. The php.net website says
(paraphrased):

You enable the MSSQL extension by adding...

extension=mssql.so

....to php.ini. (You may have to use Search in GNOME or KDE to find
php.ini on your system.) (The website says it as php_mssql.dll, but
that's incorrect on *nix! I've also not confirmed this filename
exactly, but I assume I am correct from other documentation on the
php.net site.)

Next you must recompile PHP with...

--with-mssql=<dir>

....where <dir> is the place where the FreeTDS *.so libraries are. On
RH9, that's /usr/lib.

Once you have this recompiled, you can use the mssql_* API that's
documented on php.net.

Enjoy!

THE END

{

I'm stuck. When I try to compile PHP, I tried to download some tar
file (that php.net redirected me for retrieval) called
php-4.2.2.tar.gz and then followed the instructions from "aissam at
yahoo dot com" at this URL:

http://www.php.net/manual/en/function.mssql-connect.php

However, what happens for me is that it runs configure (had to chmod
a+rwx it first, strangely) but then that never generates a make file
so that I can type "make", then "make install".

What's the trick? Where did I go wrong?

}

Hi Mike!

(...howto...)
>
>I'm stuck. When I try to compile PHP, I tried to download some tar
>file (that php.net redirected me for retrieval) called
>php-4.2.2.tar.gz and then followed the instructions from "aissam at
>yahoo dot com" at this URL:
>
>http://www.php.net/manual/en/function.mssql-connect.php
>
>However, what happens for me is that it runs configure (had to chmod
>a+rwx it first, strangely) but then that never generates a make file
>so that I can type "make", then "make install".
>
>What's the trick? Where did I go wrong?

I never tried phpize, so I cannot help with his suggestions

try

../configure
make
make install

as the installation documentation on php.net says. You also need the
apache-dev rpms.

HTH, jochen
--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/

Jochen Daum <jochen.daum@cans.co.nz> wrote:
>
> I never tried phpize, so I cannot help with his suggestions
>
> try
>
> ./configure
> make
> make install
>
> as the installation documentation on php.net says. You also need the
> apache-dev rpms.

Some guy named Frank M Kromann emailed me from some PHP website I must
have posted this question to. He had excellent advice, which I plan to
try out. He said:

You don't need to recompile and overwrite your existing PHP or Apache,
risking everything! Instead, you compile a separate PHP in order to
make mssql.so, then either (a) edit php.ini to include it, or (b) use
dl() in the top of your page to load it where necessary.

His instructions were:

1. Download the development source for your version of PHP and
platform, that includes the mssql extension.

2. Do this:

../configure --with-mssql,shared
make

>>> DO NOT TYPE "MAKE INSTALL" !!! <<<

3. This creates mssql.so. Use Search in GNOME or KDE to find where
your PHP extensions are, such as the mysql.so file, and copy your new
mssql.so file there.

4. Edit PHP.INI, or use dl() on each page where you need mssql, to
load this new mssql.so file.

Now if I could just find out how to get the PHP source for my version
of PHP. I have 4.2.2 and I don't want to go any higher than that at
this time because I have code glued to that version right now.

Any advice on where to get the PHP source for my version of PHP on
Linux? Will I need other tools?

Hi Mike!

On 24 Nov 2003 11:40:12 -0800, googlemike@hotpop.com (Google Mike)
wrote:

>Jochen Daum <jochen.daum@cans.co.nz> wrote:
>>
>> I never tried phpize, so I cannot help with his suggestions
>>
>> try
>>
>> ./configure
>> make
>> make install
>>
>> as the installation documentation on php.net says. You also need the
>> apache-dev rpms.
>
>Some guy named Frank M Kromann emailed me from some PHP website I must
>have posted this question to. He had excellent advice, which I plan to
>try out. He said:
>
>You don't need to recompile and overwrite your existing PHP or Apache,
>risking everything! Instead, you compile a separate PHP in order to
>make mssql.so, then either (a) edit php.ini to include it, or (b) use
>dl() in the top of your page to load it where necessary.
>

Its a good idea, but you are not risking much, nor does it take long.

>His instructions were:
>
>1. Download the development source for your version of PHP and
>platform, that includes the mssql extension.
>
>2. Do this:
>
>./configure --with-mssql,shared
>make
>
>>>> DO NOT TYPE "MAKE INSTALL" !!! <<<
>
>3. This creates mssql.so. Use Search in GNOME or KDE to find where
>your PHP extensions are, such as the mysql.so file, and copy your new
>mssql.so file there.
>
>4. Edit PHP.INI, or use dl() on each page where you need mssql, to
>load this new mssql.so file.
>
>Now if I could just find out how to get the PHP source for my version
>of PHP. I have 4.2.2 and I don't want to go any higher than that at
>this time because I have code glued to that version right now.
>
>Any advice on where to get the PHP source for my version of PHP on
>Linux? Will I need other tools?

Bottom of the downloads page leads to

http://www.alltheweb.com/search?cat=...p-4.2.2.tar.gz

HTH, Jochen


--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/

Latest developments:

The latest is that I can get an mssql.so compiled and loaded properly
(I think), but then the code won't work and it won't display the real
reason for the error. It displays no error at all but crashes the
script, not processing the rest of it, and then displays no error
about the crash.

RH9 comes with 4.2.2. That's like mega old. Here it is 2003 and 4.2.2
came out in like 2001. No wonder Red Hat decided that they'd need to
make the Fedora project!! For the luv of...@#%$#...geesh!

Anyway, 4.2.2 tarball won't compile on my system using the method
above, and it's ./configure --with-mssql=shared, not
--with-mssql,shared. It's =, not comma. My documentation mistake.
Anyway, it still wouldn't compile properly.

Went with 4.3.4 tarball -- was the latest stable build. Surely they
would have the mssql.so file ironed out by now. This compiled
properly, created a .so file, and I copied it to /usr/lib/php4 (where
RH9 puts the .so files).

RH9 is a little funny. The php.ini file tells you that you need to
make a file called mssql.ini in /etc/php.d directory. The
/etc/php.d/mysql.ini file should look like:

extension=mssql.so

That's it and I found that this works in loading the so properly. Of
course, other ways to load this extension are to add the line you see
above inside php.ini, or to use dl('mssql.so') to the top of your php
script.

Remember -- after editing php.ini, restart Apache.

Anyway, cool -- PHP provides 3 ways to load extensions dynamically.

Okay, so I proved that I could load the .so file without error, but
then I need the code to work. My code looks like:

<?php

dl('mssql.so'); //can comment this out if you used one of the other 2
php dynamic loading techniques
$server = '40.40.40.40,1433'; //you'll need to change
$user = 'sa'; //may need to change
$pass = 'passwordgoeshere'; //you'll need to change
echo "before connect...<BR>\n";
$conn = mssql_connect($server, $user, $pass);
echo "before select_db...<BR>\n";
$db = mssql_select_db('pubs', $conn);
echo "before query...<BR>\n";
$rows = mssql_query('select * from authors', $conn);
echo "before fetch_array...<BR>\n";
$row = mssql_fetch_array($rows);
echo "before dumping data for a row...<BR>\n";
echo $row[0] . ' ' . $row[1] . ' ' . $row[2];
exit;
?>

Well, that wouldn't work -- it stops after "before connect" without
error. So I tried changing the comma "," in $server to a colon ":".
Same result.

So, I figured I needed to change $server to "myservername", and then
add this to /etc/freetds.conf:

[myservername]
host = 40.40.40.40
port = 1433
tds version = 7.0

This had the same exact result as the previous $server variable
arrangement.

So then I tried mssql_pconnect instead of mssql_connect. Same result.

So I tried a SQL 7 server instead of 2K. Same result -- just shows the
first echo statement and never gets past that and never shows an
error.

So, here's my latest thoughts:

* The 4.3.4 mssql.so file that I generated is either a work in
progress by the PHP team, or I have a version conflict with a 4.2.2
PHP and a 4.3.4 mssql.so. I might have to go down the long road of
learning how to compile Apache with all the proper modules enabled
like they are now on my system, and compile PHP 4.3.4 in the same way.
Not looking forward to it.

* I may have to either shell out and do a tsql call from a PHP page,
which seems to work and would require parsing -- and is also not a
recommended option unless you're desperate; or, I'll need to build my
own socket server with VB6 and the Winsock control in a control array
on a Windows system, using ADO to process the incoming SQL calls from
a PHP socket call.

* Or I'll need a .so that someone has made for PHP that enables SQL
Server connections in another way.

* Or I'll use PHP to call JDBC to access MS SQL, since that works
because Microsoft has made a JDBC driver for MS SQL 2K. I don't like
that solution because it requires giving into Java, which I am trying
to abandon because PHP was so much cooler.

* So, if you're looking to do MS SQL Server connections from within
RH9, you're in for some severe fun....NOT.

Hi Mike!

On 24 Nov 2003 17:08:24 -0800, googlemike@hotpop.com (Google Mike)
wrote:

>Latest developments:
>
>The latest is that I can get an mssql.so compiled and loaded properly
>(I think), but then the code won't work and it won't display the real
>reason for the error. It displays no error at all but crashes the
>script, not processing the rest of it, and then displays no error
>about the crash.
>
>RH9 comes with 4.2.2. That's like mega old. Here it is 2003 and 4.2.2
>came out in like 2001. No wonder Red Hat decided that they'd need to
>make the Fedora project!! For the luv of...@#%$#...geesh!
>
>Anyway, 4.2.2 tarball won't compile on my system using the method
>above, and it's ./configure --with-mssql=shared, not
>--with-mssql,shared. It's =, not comma. My documentation mistake.
>Anyway, it still wouldn't compile properly.
>
>Went with 4.3.4 tarball -- was the latest stable build. Surely they
>would have the mssql.so file ironed out by now. This compiled
>properly, created a .so file, and I copied it to /usr/lib/php4 (where
>RH9 puts the .so files).
>
>RH9 is a little funny. The php.ini file tells you that you need to
>make a file called mssql.ini in /etc/php.d directory. The
>/etc/php.d/mysql.ini file should look like:
>
>extension=mssql.so


I would expect to put that in php.ini
>
>That's it and I found that this works in loading the so properly. Of
>course, other ways to load this extension are to add the line you see
>above inside php.ini, or to use dl('mssql.so') to the top of your php
>script.
>
>Remember -- after editing php.ini, restart Apache.
>
>Anyway, cool -- PHP provides 3 ways to load extensions dynamically.
>
>Okay, so I proved that I could load the .so file without error, but
>then I need the code to work. My code looks like:
>
><?php
>
> dl('mssql.so'); //can comment this out if you used one of the other 2
>php dynamic loading techniques
> $server = '40.40.40.40,1433'; //you'll need to change
> $user = 'sa'; //may need to change
> $pass = 'passwordgoeshere'; //you'll need to change
> echo "before connect...<BR>\n";
> $conn = mssql_connect($server, $user, $pass);
> echo "before select_db...<BR>\n";
> $db = mssql_select_db('pubs', $conn);
> echo "before query...<BR>\n";
> $rows = mssql_query('select * from authors', $conn);
> echo "before fetch_array...<BR>\n";
> $row = mssql_fetch_array($rows);
> echo "before dumping data for a row...<BR>\n";
> echo $row[0] . ' ' . $row[1] . ' ' . $row[2];
> exit;
>?>
>
>Well, that wouldn't work -- it stops after "before connect" without
>error. So I tried changing the comma "," in $server to a colon ":".

It always only worked for me with 40.40.40.40:1433



>Same result.
>
>So, I figured I needed to change $server to "myservername", and then
>add this to /etc/freetds.conf:
>

I'm not using this. Neither did I need any ENV setting for FreeTDS.

>[myservername]
>host = 40.40.40.40
>port = 1433
>tds version = 7.0
>
>This had the same exact result as the previous $server variable
>arrangement.
>
>So then I tried mssql_pconnect instead of mssql_connect. Same result.
>
>So I tried a SQL 7 server instead of 2K. Same result -- just shows the
>first echo statement and never gets past that and never shows an
>error.
>

Hmm. You tried the telnet again, I suppose.

>So, here's my latest thoughts:
>
>* The 4.3.4 mssql.so file that I generated is either a work in
>progress by the PHP team, or I have a version conflict with a 4.2.2
>PHP and a 4.3.4 mssql.so. I might have to go down the long road of
>learning how to compile Apache with all the proper modules enabled
>like they are now on my system, and compile PHP 4.3.4 in the same way.
>Not looking forward to it.

You don't need to compile apache to compile php. I actually have never
compiled apache. I ran it as an rpm on Suse and from a deb on debian

>
>* I may have to either shell out and do a tsql call from a PHP page,
>which seems to work and would require parsing -- and is also not a
>recommended option unless you're desperate; or, I'll need to build my
>own socket server with VB6 and the Winsock control in a control array
>on a Windows system, using ADO to process the incoming SQL calls from
>a PHP socket call.

It really must work somehow. Maybe look into tcpdump to see whats
happening under the bonnet.

>
>* Or I'll need a .so that someone has made for PHP that enables SQL
>Server connections in another way.

I would try to compile PHP from a tarball (4.3.4) and turn on mssql.

>
>* Or I'll use PHP to call JDBC to access MS SQL, since that works
>because Microsoft has made a JDBC driver for MS SQL 2K. I don't like
>that solution because it requires giving into Java, which I am trying
>to abandon because PHP was so much cooler.
>
>* So, if you're looking to do MS SQL Server connections from within
>RH9, you're in for some severe fun....NOT.


Whats exactly the reason again, why you couldn't compile PHP?

Here's my configure line for 4.3.2:

../configure --with-mysql --with-apxs
--with-crack=/var/www/install/cracklib2.7 --with-mssql --with-gd
--with-png-dir --enable-gd-native-ttf --with-ttf --with-curl
--enable-wddx --with-zlib-dir= --with-informix=/opt/informix
--enable-sockets --with-freetype-dir --with-ldap

You can remove pretty much everything, so you have

../configure --with-mysql --with-apxs --with-mssql

What is the exact problem you get with a tarball and this?

HTH, Jochen



--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/

Jochen Daum <jochen.daum@cans.co.nz> wrote:
>
>
> Whats exactly the reason again, why you couldn't compile PHP?
>
> Here's my configure line for 4.3.2:
>
> ./configure --with-mysql --with-apxs
> --with-crack=/var/www/install/cracklib2.7 --with-mssql --with-gd
> --with-png-dir --enable-gd-native-ttf --with-ttf --with-curl
> --enable-wddx --with-zlib-dir= --with-informix=/opt/informix
> --enable-sockets --with-freetype-dir --with-ldap
>
> You can remove pretty much everything, so you have
>
> ./configure --with-mysql --with-apxs --with-mssql
>
> What is the exact problem you get with a tarball and this?
>
> HTH, Jochen

My RH9 is compiled currently on 4.2.2. All other compiling I'm doing
is just to generate the .so file and sticking it in a directory
(/usr/lib/php4) for dynamic loading. I don't want to risk my 4.2.2
install. Here's a good reason why -- when I did a phpinfo(), it came
back with a gazillion configuration switches that I would need to
ensure that could compile again -- very risky. Another reason is that
I already have production code tied to 4.2.2 that works well. I'm not
ready to migrate yet.

I could not compile the mssql.so file in 4.2.2 or 4.2.3. It bombed out
on the make process saying something like missing something. Do you
care for me to type that into another newsgroup post? If so, I will.

I could, however, compile that file on 4.3.4. I then drug it to
/usr/lib/php4 and mounted it properly in php.ini. Additionally, I also
mounted it 2 other ways in other tests. There are 3 ways to mount a
..so file: php.ini, dl(), and then on RH9 there's a configuration they
have in the php.ini file to make it load other *.ini extension files
from the /etc/php.d/ directory.

When I got the .so file to mount properly, instead of mssql_* API
being confused and bombing out, saying something like, "I don't know
what mssql_connect is", it wouldn't error out and would continue
processing. The bad news, however, is that it would not generate an
error, but would just stop processing further lines past the
mssql_connect line. The script would crash, essentially, posting no
error.

BTW, I want to show you my phpinfo() info on ./configure:

'./configure' '--host=i386-redhat-linux' '--build=i386-redhat-linux'
'--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--cache-file=../config.cache'
'--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl'
'--with-dom=/usr' '--with-exec-dir=/usr/bin'
'--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd'
'--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext'
'--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr'
'--with-openssl' '--with-png' '--with-pspell' '--with-regex=system'
'--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU'
'--enable-bcmath' '--enable-exif' '--enable-ftp'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path'
'--enable-track-vars' '--enable-trans-sid' '--enable-yp'
'--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear'
'--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos'
'--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared'
'--with-snmp=shared,/usr' '--with-snmp=shared'
'--enable-ucd-snmp-hack' '--with-unixODBC=shared'
'--enable-memory-limit' '--enable-bcmath' '--enable-shmop'
'--enable-versioning' '--enable-calendar' '--enable-dbx'
'--enable-dio' '--enable-mcal' '--with-apxs2=/usr/sbin/apxs'

Hi Mike!

On 25 Nov 2003 11:59:31 -0800, googlemike@hotpop.com (Google Mike)
wrote:

>Jochen Daum <jochen.daum@cans.co.nz> wrote:
>>
>>
>> Whats exactly the reason again, why you couldn't compile PHP?
>>
>> Here's my configure line for 4.3.2:
>>
>> ./configure --with-mysql --with-apxs
>> --with-crack=/var/www/install/cracklib2.7 --with-mssql --with-gd
>> --with-png-dir --enable-gd-native-ttf --with-ttf --with-curl
>> --enable-wddx --with-zlib-dir= --with-informix=/opt/informix
>> --enable-sockets --with-freetype-dir --with-ldap
>>
>> You can remove pretty much everything, so you have
>>
>> ./configure --with-mysql --with-apxs --with-mssql
>>
>> What is the exact problem you get with a tarball and this?
>>
>> HTH, Jochen
>
>My RH9 is compiled currently on 4.2.2. All other compiling I'm doing
>is just to generate the .so file and sticking it in a directory
>(/usr/lib/php4) for dynamic loading. I don't want to risk my 4.2.2
>install. Here's a good reason why -- when I did a phpinfo(), it came
>back with a gazillion configuration switches that I would need to
>ensure that could compile again -- very risky. Another reason is that
>I already have production code tied to 4.2.2 that works well. I'm not
>ready to migrate yet.

Yes, understand that.

>
>I could not compile the mssql.so file in 4.2.2 or 4.2.3. It bombed out
>on the make process saying something like missing something. Do you
>care for me to type that into another newsgroup post? If so, I will.

Sure, why not.
>
>I could, however, compile that file on 4.3.4. I then drug it to
>/usr/lib/php4 and mounted it properly in php.ini. Additionally, I also
>mounted it 2 other ways in other tests. There are 3 ways to mount a
>.so file: php.ini, dl(), and then on RH9 there's a configuration they
>have in the php.ini file to make it load other *.ini extension files
>from the /etc/php.d/ directory.
>
>When I got the .so file to mount properly, instead of mssql_* API
>being confused and bombing out, saying something like, "I don't know
>what mssql_connect is", it wouldn't error out and would continue
>processing. The bad news, however, is that it would not generate an
>error, but would just stop processing further lines past the
>mssql_connect line. The script would crash, essentially, posting no
>error.

I wouldn't expect that to work. Its two different releases and the
extension behaviour might have changed.

>
>BTW, I want to show you my phpinfo() info on ./configure:
>
>'./configure' '--host=i386-redhat-linux' '--build=i386-redhat-linux'
>'--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr'
>'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
>'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
>'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
>'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
>'--infodir=/usr/share/info' '--cache-file=../config.cache'
>'--with-config-file-path=/etc'
>'--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect'
>'--disable-debug' '--enable-pic' '--disable-rpath'
>'--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl'
>'--with-dom=/usr' '--with-exec-dir=/usr/bin'
>'--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd'
>'--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext'
>'--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr'
>'--with-openssl' '--with-png' '--with-pspell' '--with-regex=system'
>'--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU'
>'--enable-bcmath' '--enable-exif' '--enable-ftp'
>'--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets'
>'--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path'
>'--enable-track-vars' '--enable-trans-sid' '--enable-yp'
>'--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear'
>'--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos'
>'--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared'
>'--with-snmp=shared,/usr' '--with-snmp=shared'
>'--enable-ucd-snmp-hack' '--with-unixODBC=shared'
>'--enable-memory-limit' '--enable-bcmath' '--enable-shmop'
>'--enable-versioning' '--enable-calendar' '--enable-dbx'
>'--enable-dio' '--enable-mcal' '--with-apxs2=/usr/sbin/apxs'

Ok, its huge. Is it running on Apache2 as well? I'm just surprisd
about the last switch. Also, a lot of this stuff is the default
setting, but its good to be explicit.

HTH, Jochen


--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/

Jochen Daum <jochen.daum@cans.co.nz> wrote:

> --with-apxs2=/usr/sbin/apxs'
>
> Is it running on Apache2 as well?
>

Yes. Apache 2.

Nope. Couldn't get FreeTDS or any variation of TDS to work. Had to
write my own driver. TDS works for me only at command line and via
Tora or other GTK+ SQL tool on my Linux box. Doesn't work via my
version of PHP (4.2.2).

ODBC acts the same way.

This all probably stems from the fact that I'm on PHP 4.2.2, not the
latest version of PHP.

So, instead...

I took my multithreaded Telnet socket service that I built last year
in VB6 and converted into a multithreaded Linux-MSSQL bridge.

Comes back with 4000 rows pretty darn quickly. Comes back with more
rows than that pretty good, but I wouldn't see conceivably why anyone
would want to make a web page ask for more than 4000 rows on
something. That's one of the great uses of stored procedures -- to
isolate data down to just what you need.

Also executes commands (including EXEC, UPDATE, INSERT, DELETE, etc)
and returns the number of rows affected.

Also returns error messages when they occur.

Gosh. It's so cool I could almost turn it over as open source to the
world at large, but that would require copyrighting, trademarking,
then turning it over to a committee to manage it on SourceForge.

I'm writing a PHP class now that abstracts this bridge so that one can
talk to it almost like they use the mssql_* API in PHP. Since the
mysql_* APIs in PHP look to be the standard, I'll try to cater them to
that, however.