I worked on a project with a MS SQL server 2008 containing data of NVARCHAR type in multiple languages,
including asian characters. It is a known issue, that the PHP MSSQL functions are not able to retrieve
unicode data form NVARCHAR or NTEXT data fields.

I spent some time searching for possible solutions and finaly found a work arround, that provides correct
display of latin and asian fonts from a NVARCHAR field.

Do a SQL query, while you convert the NVARCHAR data first to VARBINARY and then to VARCHAR

SELECT
CONVERT(VARCHAR(MAX),CONVERT(VARBINARY(MAX),nvarchar_col)) AS x
FROM dbo.table

While you fetch the result set in PHP, use the iconv() function to convert the data to unicode

<?php $x = iconv("UCS-2LE","UTF-8",$row['x']); ?>

Now you can ouput the text to UTF-8 encoded page with the correct characters.

This workarround did run on IIS 6.0 with PHP 5.2.6 running as FastCGI.

Install And Configure FreeTDSThe first thing you need to do is to download and install the FreeTDS driver. You can get the source and compile it yourself from http://www.freetds.org/, but I prefer RPMs. Depending on your distrobution of Linux, the version you want will vary. I'm running Red Hat Enterprise Linux 4 ES and CentOS 4, which are both almost identical. I installed freetds-0.62.3-1 from http://rpmforge.net/user/packages/freetds/After installing FreeTDS, you can check your driver by attempting to connect to the MSSQL Server. Of course, use the appropriate server name, username and password in your command line.# /usr/bin/tsql -S [mssql.servername.or.ip] -U [ValidUser]locale is "en-US.UTF-8"locale charset is "UTF-8"Password: [password]1>Enter "quit" to exit your successful connection. If the tsql command doesn't return the 1> prompt, verify that you can get to your MSSQL server with telnet [mssql.servername.or.ip] 1433 and that your username and password are valid.Next, edit your /etc/freetds.conf configuration file and add the following at the end of the file:[TDS] host = [mssql.servername.or.ip] port = 1433 tds version = 7.0 Setup ODBC Data SourceNext, unixODBC needs to know about all ODBC drivers you intend to use. While you can use the GUI program that comes with unixODBC, you can also use the odbcinst command. First create a template file containing your FreeTDS setup information.tdsdriver.template[FreeTDS]Description = v.062 with protocol v7.0Driver = /usr/lib/libtdsodbc.so.0Run odbcinst, telling it to install a driver entry using the template we just created.# odbcinst -i -d -f tdsdriver.templateodbcinst: Driver installed. Usage count increased to 1. Target directory is /etcThis will add an entry to the end of the file /etc/odbcinst.ini[FreeTDS]Description = v0.62 with protocol v7.0Driver = /usr/lib/libtdsodbc.so.0UsageCount = 1

It appears ntwdblib.dll is no longer a part of SQL 2005. According to Microsoft the component is deprecated and they recommend using OLE DB or ODBC. The dll from SQL Server version 6.5, SQL Server 7.0, or SQL Server 2000 still works against 2005 if you have it.

From Microsoft's site:

Although the SQL Server 2005 Database Engine still supports connections from existing applications using the DB-Library and Embedded SQL APIs, it does not include the files or documentation needed to do programming work on applications that use these APIs. A future version of the SQL Server Database Engine will drop support for connections from DB-Library or Embedded SQL applications. Do not use DB-Library or Embedded SQL to develop new applications. Remove any dependencies on either DB-Library or Embedded SQL when modifying existing applications. Instead of these APIs, use the SQLClient namespace or an API such as OLE DB or ODBC. SQL Server 2005 does not include the DB-Library DLL required to run these applications. To run DB-Library or Embedded SQL applications you must have available the DB-Library DLL from SQL Server version 6.5, SQL Server 7.0, or SQL Server 2000.

I managed to get a connection to the SQL server, but found that when I used the function mssql_query() to pass in a Select statement containing datetime columns, I would get the following message in Internet Explorer - "The page cannot be displayed". When I removed the datetime column from the query, it worked fine, and returned a resultset.Looked in the apache error.log file, and found the error "child pid xxxxxx exit signal segmentation fault".

After a lot of searching on the internet I stumbled upon an entry which was missing from my php.ini. I added the line "mssql.datetimeconvert = Off" to the MSSQL section of pphp.ini, restarted Apache, and the problem went away. Now I can select dates in SQL queries

PHP Warning: mssql_query(): message: Unicode data in a Unicode-only collation or ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier. (severity 16) in /var/www/html/query.php on line 29

There are two solutions: one solution involves casting the data types in the query, the other solution involves changing the version number free tds is using.

The first solution is mentioned all over the web and limits what you can return, the second solution will probably only be found right here.

Open up your free tds configuration file (/etc/freetds.conf), and change:

[global]tds version = 4.2

to this:

[global]tds version = 8.0

You don't have to upgrade any packages, but by default, freetds tries to use an older version (if you installed freetds using yum or apt-get).

FYI if you are on Linux and using FreeTDS for your drivers (you most likely are), you can get past the 255 character limit by:

1. open the file freetds.conf (normally in the directory /etc)2. under [global] section change the "tds version" to "7.0" or "8.0" (depending on your version of SQL Server)3. changes should be instant!

If you are experiencing that ANSI characters are being corrupted, e.g. nordic letters are showing up as invalid characters and you have SQL Server 2000 installed on the same machine as the webserver, try checking SQL Server Client Network Utility under the DB-Library Options tab.Make sure that "Automatic ANSI to OEM conversion" is NOT checked, this caused me several hours of headache.

I tried all manner of things in order to cnnect to SQLExpress aka SQL Server 2005 and was just about to walk away and move across to MySQL when it just dawned on me that after following all of the instructions from numerous people I never restarted the Apache service.

This meant that the new ntwdblib.dll was never called. I restarted the service and hey presto ... I can now connect to the SQL server.

The items that I did were as follows:

1. Installed the SQLServer in mixed auth mode2. Checked that the mssql.secure_connection = Off was present in the php.ini3. Copied the ntwdblib.dll file into o WINDOWS\SYSTEM32 o program files\apache2\bin o php4. Started the SQL Server Browser Service5. Enabled all of the IPs in Protocols > TCP/IP6. Restarted the following services: o Apache o SQL Service o SQL Browser Service

This allowed me to connect with no problems using the following parameters within my mssql_connect call

MSSQL doesn't have a real_escape_string function like MYSQL does, which can lead to error when inserting or updating data that contains a ' (single quote).

To prevent this, replace all ' (single quotes) by TWO ' (single quotes) '' which SQL server will interpret as an escaped '.Also you may want to remove any \' \" escape sequences that are translated from any FORM output into the PHP $_POST variables.

First create a test which detects this to be the problem and then self correct it.

For the times that this is a problem rename the columns to an unique column name which is 30 characters exactly in length. This column must be unique compares to the others, so use the MD5 Hashed value. Since MD5 hashed values are 32 character HEX values, convert this to a toggle Hex value giving an exact maximum length of 31 characters. Prepend a character to the start to ensure that it falls within Column naming regulations.

When the data is obtained, check for the hashed values against a check array and replace where neccessary.

Although complex it may sound, the method has been tried and successfully works, thus allowing columns of greater length than that of 30 characters.

I had this situation within Linux as well as Windows (XAMPP), so this solution was ultimate in solving the problem.

You can run the detection as a constant or automatically. However it is best to use a constant for efficiency reasons.

If your having problems with your script at random times refusing to connect to the database. Try editing php.ini and uncommenting this line.

mssql.max_procs = -1

This solved the problem for me after 3 days of pulling my hair out wondering why it kept refusing to connect!

==

[Because this may not always work,] I created a loop to create a few connections and noticed it was always the first connection that failed. So I wrote this to keep trying to connect until it eventually does.

FINNALLY got PHP to connect to MS SQL Server. Even though I read through the multitue of comments about ntwdblib.dll, etc., I still couldn't get it to work. The key was to load the Microsoft MDAC (2.8) on my IIS/PHP server. If your environement does not use the web server to host SQL as well, you will probably need to install the MDAC. My guess is that an installation of SQL Server (and/or just the client tools) on the webserver will automatically include the MDAC and you would not experience this problem.

Couple of notes:
When setting this up, you might notice that the unixODBC isql command likes the password wrapped in single quotes:
isql -v MyDSN MyUserID 'MyPa$$W0rd'

Additionally, if you happen to have a dollar-sign in your password (or username, or DSN) -- you must avoid using double quotes. This is a normal PHP gotcha, but worth mentioning.
Won't work:
<?php $con = mssql_connect ("MyDSN", "MyUserID", "MyPa$$W0rd"); ?>

I have found that a Windows Webserver cannot connect to a Microsoft SQL Database if the webserver is running Microsoft SQL Server Agent. It gives connection and undefined function errors. Hope this helps some people.

I had major problems trying to get the msssql extension loaded. The following fixed it for me:

1. Make sure the ntwdblib.dll file located in system32/ on the Database server is copied to system32 on the PHP serving server.2. Uncomment the extension in the php.ini file.3. Add the following to the registry: [HKEY_LOCAL_MACHINE\SOFTWARE\PHP]"IniFilePath"="C:\\PHP"This tells PHP where to find the php.ini(This is what my resolution to my problem was - only after some time did I find some reference to it).4. Restart IIS

The 3 major headaicks I had while setting up MS SQL 2005, php 5.1.6 (apache 2.2 server) on Vista RC1 and getting them to comunicate.

TCP/IP and "Named Pipes Protocol" had to be enabled in the MS SQL Server. You do this in the Surface Area Configuration tool.

MS SQL 2005 should be set to mix mode login. Unless you use NT authentication in php.ini.You can do this in duing install if you select advanced options.If it's already installed you will have to use the SQL management Studio (properties->securety).

At first the php_mssql.dll didn't load properly (wan't showing up under phpinfo()) and gave no error message at startup, the cause of this was the ntwdblib.dll that came with php (273KB) replacing it with the one that came with MS SQL 2005 (269KB) fixed the issuse, incase you haven't installed MS SQL on your machine you can also find it on the net.

I had major latency problems with DB connections using php_mssql.dll without the client tools. I found that by default it was using TCP/IP as the default connection method. Installing the SQL Server client tools and using the Client Network Utility to change my settings to use named pipes resolved this issue. You can use the Client Utility to set up a named pipes server alias and reference that in your connect string.

We had some, read A LOT, of problems with MSSQL under Windows 2003. We had 2 the same windows, php, php-ini, everything machines but only one could connect. Unable to connect was the error message.

Finnaly we checked the version of ntwdblib.dll and the one distributed with PHP was 7.00.... and the version of the one on the SQL Server install was 8.00.... so we copied this one in the php and apache dir and it worked.

I have integrated authentication enabled in IIS. I kept getting CGI timeouts on PHP pages for everyone but local administrators of the box. The event log showed that PHP could not load php_mssql.dll, php_oci8.dll, and php_oracle.dll - 'Access Denied.'

These extensions were executable by everyone, but the DLLs they depend on were not. Had to add exec permissions for everyone to c:\winnt\system32\ntwdblib.dll as well as the oracle bin directory.

I've spent the last three days wild guessing why I could not connect to MS SQLServer 2000 and so I hope this might help someone else. Microsoft has purposefully closed the 1433 tcp port and others (maybe only to external ips) of the server. You can easily check if this is the case by looking at the Event Monitor. You should see an error produced by MSSQL SERVER/MSDE that basically says what I said. It suggests downloading and installing a security patch to open up the ports (but doesn't even say which update - remember this is Microsoft).

I was having problem in connecting Ms-SQL server with mssql_connect(srvr,uid,pwd). I used odbc functions to connect to Ms-SQL server. I was on a work station and server was not accessible for unknow reasons. mssql functions did not work there so I had to use odbc. I simply created a DSN to my Database and replaced it with "server_name". i.e.

Buried away in the mssql_field_length documentation is an important limitation that it is certainly worth knowing about *BEFORE* you do any database design:

Note to Win32 Users: Due to a limitation in the underlying API used by PHP (MS DbLib C API), the length of VARCHAR fields is limited to 255. If you need to store more data, use a TEXT field instead.

SQL Server natively supports VARCHAR up to 8000 characters. Note that TEXT fields have substantially poorer performance (and are much more limited) than VARCHAR so you may want to design your databases accordingly...

You can also work around this limitation with the following:

-- for example, with MyVarCharField VARCHAR(1000) SELECT CAST(MyVarCharField AS TEXT) FROM MyTable

If you are having problems connecting to MS SQL using the mssql PHP extension then I would suggest that you get a copy of the latest NTWDBLIB.DLL. Copy it to the directory where PHP expects to find it's dll files.

I had an issuse whereby I was unable to connect to a MS SQL Cluster and this resolved my problem.

Ok, this took me a few days to get right but for those of you out there having a hard time with getting PHP to talk to SQL 2000 this is for you! Personally for me the mssql plugin barely worked with sql 2000 and was VERY slow, here's your solution and also some good code to connect securely and quickly through ADO. I was having the worst time getting ADO to work as well, most sites do the driver part a different way.. for me the code below is the only thing that worked.

i was originally trying to solve an error message of "Unicode data in Unicode-only collation or ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier" and found this solution.

If you have problems getting the mssql functions to work try these varibles. MSSQL/PHP has problems dealing with different tds versions. 7.0 seems to work well with our server version, maybe a different version would work better with yours.

If you're going to use freeTDS just to access mssql databases, supply the "--enable-msdblib" switch to the freeTDS configure script when building the library. This will fix some obscure problems, like the month in a date not being displayed correctly, more information in http://www.freetds.org/userguide/config.htm.

there's no documentation of the php.ini option mssql.secure_connection.

so i have here a MS SQL 2000 Server with Windows Authentication and a Windows 2003 Server with IIS 6. So it is clear that i cannot use the usual handling of a mssql_connect. I turned the mssql.secure_connection on.I let the Windows IIS to run under an Service Account(normal user account without any special rights) in a Windows Domain, so i do have a authenticated connection to the SQL Server...

I'm using IIS 6.0, PHP 5.2 (issapi) and MSSQL.I've had Problem to connect with PHP to MSSQL.The Errormessage was that Loginname was incorrect.

My Solution is to set mssql.secure_connection = offand create an MSSQL-Account (No Windows Authentification!) and connect to MSSQL Server. It works!

If you like to use Windows Authentification, you can use the Apache Service with your desired Account and set mssql.secure_connection = on. Then you can use the mssql_connect() function without user/pwd.I don't know how this works with IIS 6.0 Server.

This occurred regardless of the username and the password that I passed to mssql_connect()

Apparently the username and password parameters are ignored when connecting to SQL Server with trusted connections. Instead it attempts to connect using the Web Server username and password instead. Under windows the default webserver account is the machine name (which is probably not set up as being a windows user).

This can be solved by configuring Apache to log on as a designated user.- Open Control Panels- Double click administrative tools- Double click services- Right click on Apache and choose properties- Under the "Log On" tab choose "This Account" and type in a valid domain user account & password- Restart the Apache service

Having trouble connecting to a MS SQL Server from Windows server with Apache + PHP, or some other server-configuration?

Too old MDAC in Windows may be your problem.

Here is a summary for those working on Windows-plattform:

1. Update your Microsoft MDAC (search for Microsoft Data Access Components on www.microsoft.com). Some older Microsoft servers (or workstations) contain old and crappy MDAC-installations. This solved our problem after two days of work..

2. Make sure ntwdblib.dll (version 8.00.194) is in the correct place(s). I only placed it in Apache bin directory and it worked fine, but apparently some Microsoft installations need it in several locations.. this is indeed very confusing!

after a few hour ,I found the problem was caused byntwdblib.dll ,which version is 7.00.839 ,when I replaced old ntwdblib.dll with the new ntwdblib.dll ,which version is 8.00.194 ,all problem are solved.