php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #38965 mssql_connect doesn't use TCP 1433 for external SQL Server
Submitted: 2006-09-26 17:16 UTC Modified: 2007-08-17 16:31 UTC
Votes:6
Avg. Score:4.7 ± 0.5
Reproduced:5 of 5 (100.0%)
Same Version:4 (80.0%)
Same OS:4 (80.0%)
From: aren at cambre dot biz Assigned: fmk (profile)
Status: Closed Package: Documentation problem
PHP Version: 4.4.4 OS: Windows 2003 (for both servers)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: aren at cambre dot biz
New email:
PHP Version: OS:

 

 [2006-09-26 17:16 UTC] aren at cambre dot biz
Description:
------------
When using mssql_connect to connect to a SQL Server database on a remote server, PHP attemtps to connect using named pipes. This is a terribly outdated behavior; SQL Server connections these days are almost always done with TCP 1433.

I figured this out with a difficult phpBB installation and using Wireshark (formerly Ethereal) to watch network traffic. There is a registry hack that can force the SQL Server Client program to use TCP 1433, but this hack's effects on other software is unknown.

For more info, see http://people.smu.edu/acambre/blog/2006/09/22/Buggy+PHP.aspx and http://www.phpbb.com/phpBB/viewtopic.php?t=446662&postdays=0&postorder=asc&start=0

Reproduce code:
---------------
Just use mssql_connect to connect to an external database.

Expected result:
----------------
The database should open just as if the database is on localhost.

Actual result:
--------------
Usually a cannot connect error.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-09-26 17:25 UTC] tony2001@php.net
Frank, is this really a PHP problem?
 [2006-09-26 17:35 UTC] fmk@php.net
No PHP uses ntwdblib and if you install the Client tools from MSSQL server you can define the default protocol. Older versions of ntwdblib (or combinations of other MS tools installed) uses named pipes as the default.

The best way is to install the Client Tools and us the Clinet Network utility to set default protocol as well as create aliases for different servers. Each alias can be defined with the prefered protocol.
 [2006-09-26 18:23 UTC] aren at cambre dot biz
This ntwdblib was on a default installation of Windows Server 2003.
 [2006-09-26 19:15 UTC] aren at cambre dot biz
Lemme add some more info:

The IIS (web) server is a really vanilla Windows Server 2003 box. All that is installed, per Add or Remove Programs, is McAfee VirusScan Enterprise, Microsoft .NET Framework 2.0, PHP 4.4.4, and WMware Tools (it's virtual). I also installed Wireshark 0.99.3 and WinPcap 3.1, but they were installed afte the fact and did not affect the issue.

If PHP's SQL Server connect script doesn't work right on a vanilla box, I can't believe this is "bogus". SQL Server or SQL Server Client Tools has never been installed on this box.

Programs should adhere to industry standard behaviors on vanilla Windows boxes, and industry standard for talking to SQL Server is TCP 1433. If PHP is not doing it, it needs to be fixed or properly documented.

It may be as simply as classifying this as a documentation bug and adding documentation that addresses the issue, if that is the proper solution.
 [2006-09-27 21:23 UTC] fmk@php.net
The MSSQL Extension for PHP uses ntwdblib as the library to connect to teh server. The configuration of this library is done with MS SQL Server Client Tools. These tools are installed from the CD and can be installed without the rest of the server to allow remote connections to the server.

If ntwdblib.dll is copied to the server one way or the other, there is no way (except for registry hacks) to configure the library. PHP is not responsible for installation of a Microsoft tool or any other 3rd party libraries, but we expect them to be installed correct.

There is no bugs in PHP here.

 [2006-09-28 03:18 UTC] aren at cambre dot biz
There is a clear documentation error. From http://us3.php.net/manual/en/ref.mssql.php: "The Client Tools can be installed ... by copying ntwdblib.dll from \winnt\system32 on the server to \winnt\system32 on the PHP box. Copying ntwdblib.dll will only provide access. Configuration of the client will require installation of all the tools."

The method suggested by the manual, simply copying the ntwdblib.dll, will force PHP to use named pipes. This needs to be documented. Until then, you have a documentation bug because PHP will be unable to talk to SQL Server in its industry standard configuration (i.e., TCP 1433, not named pipes) if you simply copy the DLL on a machine that does not have the SQL Server Client Tools installed.
 [2007-02-28 11:05 UTC] mds135 at yahoo dot co dot uk
We have the same problem, where we get the message "mssql_Connect() not a defined function.

We are using version 4.4.5 of PHP on Windows Server 2003.

We have found out from forums that we should use an older version of the ntwdblib.dll, but we  are unable to find an older version.

We use HTMLkit as an editor, and connection works fine when we display the page in the editor's preview.  The problem occurs when we use the browser, MS Explorer 6 with SP1.

This is extremly important to us.
 [2007-02-28 11:08 UTC] tony2001@php.net
Reclassified as docu problem.
 [2007-08-17 16:31 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.

"Copying ntwdblib.dll will only provide access through named pipes."
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 13:01:29 2024 UTC