php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #42544 mssql_select_db changes all open connections OR new_link boolean doesn't work
Submitted: 2007-09-04 14:31 UTC Modified: 2009-11-23 12:46 UTC
From: walter at wjd dot nu Assigned:
Status: Closed Package: Documentation problem
PHP Version: 4.4.7 OS: linux/debian, linux/ubuntu
Private report: No CVE-ID: None
View Developer Edit
 [2007-09-04 14:31 UTC] walter at wjd dot nu 
Description:
------------
The new_link boolean in mssql_connect does not do what its supposed to do for me. When select_db'ing the second open link, the first link gets affected. var_dump tells me that both connections are the same.

When I'm using mssql_pconnect instead of connect, I do get another resource number for the second connection, but the bug that selects the wrong database, still remains. 

Is this a wrong version thing? Does mssql_select_db/mssql_query use the wrong database handle? Does the new_link boolean not work as it should?

I'm lying about the PHP version in the select box; I don't have that exact version lying around. But I've seen that this bug was dismissed in March 2006 (http://bugs.php.net/bug.php?id=36639) when there was no 4.4.7.
Latest version I've tested it on, is (I've tested on 4.4.4 as well):

$ php5 -v
PHP 5.1.6 (cli) (built: Jul 17 2007 17:45:52)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
$ dpkg -l *sybase | grep syb
ii  php5-sybase    5.1.6-1ubuntu2.6 Sybase / MS SQL Server module for php5


Reproduce code:
---------------
<?php

// call me as:
//   php5 test.php server user pass database_right database_wrong
// or: 
//   php5 test.php server user pass database_right database_wrong bug
// when calling with 'bug' you get success for the wrong reason.

$users = mssql_connect($argv[1], $argv[2], $argv[3], true);
mssql_select_db($argv[4], $users);

$management = mssql_connect($argv[1], $argv[2], $argv[3], true);
mssql_select_db($argv[5], $management);
if (@$argv[6] == 'bug')
        mssql_select_db($argv[4], $management);

echo '$users: '; var_dump($users);
echo '$management: '; var_dump($management);

if (($q = mssql_query("SELECT TOP 1 LDN_id FROM LEDEN", $users)))
        echo "\nSuccess!\n";
else
        echo "\nFailed!\n";

?>

Expected result:
----------------
$users: resource(4) of type (sybase-ct link)
$management: resource(5) of type (sybase-ct link)

Success!

Actual result:
--------------
$users: resource(4) of type (sybase-ct link)
$management: resource(4) of type (sybase-ct link)

Warning: mssql_query(): Sybase:  Server message:  Invalid object name 'LEDEN'. (severity 16, procedure N/A) in /tmp/test.php on line 14

Failed!

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-09-05 11:25 UTC] walter at wjd dot nu 
So.. I think I've figured it out (I untarred php4-STABLE-200709041230 to have a look). It's a documentation problem and a lacking feature.

I'm to be using the sybase(_ct) package (on debian and ubuntu). According to apt-cache, this is the standard package for mssql php support.

This sybase module PHP_FALIAS'es mssql_connect to sybase_connect. sybase_connect does not take the 'new_link' boolean but a 'charset' string.

Which leaves me with the two following problems; one documentation "bug" and one RFE:
- When looking at the mssql_connect manual, I'd like to be informed that I should be looking at sybase_connect if I'm using sybase_ct.so.
- I'd like a new_link boolean added to sybase_connect :)

Greetings,
Walter Doekes
 [2007-09-10 16:24 UTC] fmk@php.net 
When you use the mssql_* functions from the sybase-ct extension, you should also use the documentation for the sybase_* functions. In this case the mssql_* functions are aliases for the same functions.

If you want to have all the functions documented (and implemented) for the mssql extension you should compile PHP using --with-mssql.
 [2008-11-10 11:15 UTC] vrana@php.net 
Please specify what exactly should be documented.
 [2008-11-11 22:11 UTC] walter at wjd dot nu 
I'm sorry. I didn't think my comments left that much room for interpretation. I'll go very very slow:

1) noob user installs php and sybase_ct (because his package manager tells him that that's the way to connect to MS-SQL databases)
2) noob user looks for mssql functions
3) noob user finds mssql_* functions that seem to work, except for the mssql_connect function's fourth parameter which looks like its broken.
4) but wait, it is not broken. noob user is looking in the wrong place.

I don't know who came up with the FALIAS'ing of mssql_* to sybase_* in the sybase_ct module. But the fact that the mssql_* functions do not do what they advertise means that (1) either sybase_ct is broken because it implements documented functionality in the wrong way or that (2) the documentation is wrong.

The simplest fix is a big red warning sign on the mssql_connect page that says: """Hey noob! If you have sybase_ct.so in your php.ini, you're should be loooking at sybase_connect."""
 [2008-11-18 01:00 UTC] doc-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2008-11-22 22:28 UTC] walter at wjd dot nu 
How is that no feedback? Did I forget to tick a box?
 [2009-11-23 12:46 UTC] svn@php.net 
Automatic comment from SVN on behalf of vrana
Revision: http://svn.php.net/viewvc/?view=revision&revision=291197
Log: Warn about Sybase (bug #42544)
 [2009-11-23 12:46 UTC] vrana@php.net 
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Jul 06 13:01:35 2025 UTC