Thanks for that Info, why is it the best information like this is hidden?
This sort of thing should be documented, don't you agree?  The unix solution
sounds interesting - I'll certainly look into it for other projects (this
client actually moved away from Linux/Apache to Win2000/IIS due to lack of
staff with Linux knowledge).

Thanks for the info and the work around


-----Original Message-----
From: Brian Bruns [mailto:[EMAIL PROTECTED]]
Sent: 03 February 2002 22:53
Cc: Php-Db ML
Subject: Re: [PHP-DB] Is ODBC now the Native interface for MS-SQL7/2000

Technically, it is not the dblib interface that limits you to 255
character varchars.  TDS (tabular datastream, the on the wire protocol)
version 4.2 (the version used upto SQL Server 6.5) is limited to a single
byte size field and thus 255 characters (0 represents NULL).  The problem
is that MS seems not to support dblib at any other protocol revision that
would support it (7.0, 8.0).  So, yes, ODBC or OLE-DB would be the only
support way of accessing large varchars.  Part of the problem resides in
the fact that TDS 7 and above ships data in unicode (UCS-2) and converting
to single byte representation for dblib is a pain.

The one workaround I know of is to issue your query like "SELECT
convert(text, mycol) FROM mytable" that forces the large varchar to a text
datatype and allows you to pull it from TDS 4.2.

Under Unix you may use FreeTDS where we allow you to use dblib with TDS 7.
But that's a story for another day. ;-)


On Sun, 3 Feb 2002, Oliver Cronk wrote:

>  After looking at the newsgroup microsoft.public.sqlserver.odbc I came
> across
>  the follwing piece of information - anyone know if it is true?  It would
>  certainly explain a few things (why we can only get 255 chars out of
>  varchars etc).  Should I move my code over to ODBC?  I have tried but the
>  ODBC driver appears to lack any decent output (-1) for the odbc_num_rows
>  function - which breaks my existing code (it performs checks on the
> of
>  rows).
>  Anyone have any information about this?  Should I talk to the
> of
>  the MSSQL extension do you think?  IF it is true then the php docs should
> at
>  least illustrate this point as a warning.
>  [start of ms post]
>  They don't provide one because db-lib is a dead interface and hasn't been
>  upgraded in 5+ years now.
>   fyi - ODBC and OLE-DB *ARE* native interfaces to SQL Server - it is
>  you
>  should be using.
>  [person who asked the question wrote]
>  > Why has Microsoft not provided a new ntwdblib.dll file for SQL Server
>  2000?
>  > Clients, such as Crystal, rely on this being valid for the current
>  database.
>  > Crystal provides p2ssql.dll that communicates with ntwdblib.dll.  Since
>  > ntwdblib.dll was last updated with SQL Server 6.5, the p2ssql.dll
>  > fails for clients.
>  >
>  > For example, column names > 30 chars in length don't work in Crystal if
>  you
>  > use the p2ssql.dll driver (that communicates with the very outdated
>  > ntwdblib.dll library).  There are several other issues with this as
>  >
>  > As a result, clients such as Crystal must use a more generic ODBC
>  > (p2sodbc.dll).  That works fine, but why doesn't MS provide a current
>  > driver to work with SQL Server 2000?  Where can I get a NEW
>  to
>  > install?  I installed the latest MDAC and that didn't solve the
>  > Thanks.
>  [end of ms post]
>  Thanks for any pointers anyone throws up.
>  Oliver Cronk
>  p.s. this was found under the thread Re: ntwdblib.dll (Native vs. ODBC
>  driver) on microsoft.public.sqlserver.odbc over the last couple of days
> (and
>  so should still be there if anyone else wants to look at the entire
> thread).

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to