php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23319 Problem FreeTds 0.61 with DB Pear
Submitted: 2003-04-23 12:44 UTC Modified: 2003-06-02 17:24 UTC
From: cristianoarnold at yahoo dot com dot br Assigned:
Status: No Feedback Package: PEAR related
PHP Version: 4.3.2RC1 OS: Suse UnitedLinux 1.0
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2003-04-23 12:44 UTC] cristianoarnold at yahoo dot com dot br
Hi 
I have installed apache-ssl 1.3.27 with Php 4.3 with Classes DB Pear 1.3 and Client Sybase 11.9.2
in the Suse UnitedLinux 1.0 to connect in the Sybase ASE 11.9.2 . I work very well.

Now, I removed the client sybase and installed FreeTds 0.61, because I want to connect in the
MsSql 2000 and Sybase Ase 11.9.2 of the same web server. 

MsSql 2000
When I change the configuration of the my web pages to connect in the MsSql using DB Pear, all 
work well, except the function is_null that it returns a wrong result.
The test IF that are returns a wrong result is:
In the table USER from database MsSql exists one column called "DateThatBlockedThePassword" that 

have value NULL to user 'adminitrator' and the date '04/15/2003' to user 'operator'
The test in my  php web page is:
<?
...
$dsn = "mssql=db_user:my_password@sql_server/databasetest";
$db_conn = DB:connect( $dsn );
$sql = select UserCode, DateThatBlockedThePassword] from USER where LoginName = 

$_POST["LoginName"];
$if( DB:isError( $query_user = $db_conn->query( $sql ) {
    echo "Failed";
    exit( $query_user->getMessage() );
}

$array_user = $query_user->fetchRow( DB_FETCH_MODE_ASSOC );

if ( is_null ( $array_user[ DateThatBlockedThePassword]  ) )  {
       ..."execute others query , etc"
}
...
?>

This result is returning FALSE to both the users ;
When I remove this test, the script work correctly.

To Sybase
When I change the configuration of the my web pages to connect in the Sybase using DB Pear, occur 

a other error.

<?
...
$dsn = "sybase=db_user:my_password@sybase_server/databasetest";
$db_conn = DB:connect( $dsn );
$sql = select UserCode, LoginName, UserPassword from USER where LoginName = $_POST["LoginName"];

$if( DB:isError( $query_user = $db_conn->query( $sql ) {
    exit( $query_user->getMessage() );
}
...
?>

Return the message

Warning: Sybase message: Changed database context to 'databasetest'. (severity 10) in 

/usr/local/php/lib/php/DB/sybase.php on line 68
DB Error: DB backend not capable select UserCode, LoginName, UserPassword from USER where 

LoginName = 'administrator'

Obs. The db_user that is used to connect in the Sybase ASE have default database configured to 

'databasetest'

Procedures from the Instalation to:
--FreeTds--
./configure --prefix=/usr/local/freetds --with-tdsver=8.0 --enable-sybase-compat --enable-msdblib
make && make install
export SYBASE=/usr/local/freetds
export LD_LIBRARY_PATH=$SYBASE/lib
export PATH=$PATH:$SYBASE/bin

interface file in /usr/local/freetds/interfaces have:
sql_server
    query tcp 8.0 192.168.1.10 1433

sybase_server
    query   tcp 5.0 192.168.1.100 4100
    master tcp 5.0 192.168.1.100 4100

--PHP--
./configure --prefix=/usr/local/php --with-apache=../apache-1.3.27 

--with-sybase=/usr/local/freetds with-pgsql=/usr/local/pgsql --with-openssl=/usr/local 

--with-mcrypt=/usr/local
make && make install

php.ini have
[Sybase]
sybase.min_message_severity = 11
sybase.min_server_severity = 11
sybase.interface_file = /usr/local/freetds/interfaces
[MSSQL]
sybase.min_message_severity = 10
sybase.min_server_severity = 10

---Apache--
./configure --prefix=/usr/local/apache --activate-module=src/modules/php4/libphp4.a
make && make install

What it can be wrong. 
That is an FreeTds bug?

Obs.
I have same web pages in the IIS 5.0 web server with Windows 2000,  client native to ( MsSql 2000 

and Sybase ASE 11.9.2) , PHP 4.3 with classes DB Pear and it work well. 

Best Regards

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-04-28 04:10 UTC] arnaud@php.net
Is it for you lukas ?
 [2003-04-28 04:14 UTC] lsmith@php.net
nope .. maybe Markus can tackle this one?
 [2003-04-28 05:23 UTC] mw21st@php.net
I have no experience at all with Sybase, so I can?t help with that one.

But I have indeed had some problems with using the Sybase extension to connect to an MSSQL 2000 server. If you want to do that, it would be wise to upgrade to PHP 4.3.0 - from that version on, it?s possible to compile the MSSQL extension natively under Linux.

It?s a lot better to work with the MSSQL extension, as it offers many functions the Sybase extension does not support. I don?t know if it will help with this particular problem, though - but if it works on Windows, chances are it will.

Another alternative is to try the ODBTP extension available at SourceForge: http://odbtp.sourceforge.net/
I have no experience with that one, but it sounds very promising. So try this if nothing else helps.

If you?re having problems with retrieving DATETIME fields, it often helps to convert the date values to VARCHAR, formatted in standard ISO date format. A query like this:
SELECT CONVERT(varchar,mydatefield,20) AS mydate FROM table
...will result in a string like this:
2003-04-28
...while without that conversion, chances are it would have looked like this:
28 Apr 2003
...which is pretty useless in most cases.

These are the things that helped me to get things running - hope some of this might help you as well.

 [2003-04-28 05:31 UTC] mw21st@php.net
Addition:
Regarding your MSSQL test script, if a NULL value from the database is returned, this doesn?t mean the *type* of the respective variable in PHP really is null.
I?d rather say this variable is simply empty, which is not the same thing. So if you change your if statement from
if (is_null(...)) to if (empty(...)), things should work.

 [2003-05-26 08:55 UTC] arnaud@php.net
Did markus comment help ?
 [2003-06-02 17:24 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Thu Jun 27 06:01:31 2019 UTC