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. ;-) Brian 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 amount > of > rows). > > Anyone have any information about this? Should I talk to the developer(s) > 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 these > 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 driver > > 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 well. > > > > As a result, clients such as Crystal must use a more generic ODBC driver > > (p2sodbc.dll). That works fine, but why doesn't MS provide a current > NATIVE > > driver to work with SQL Server 2000? Where can I get a NEW ntwdblib.dll > to > > install? I installed the latest MDAC and that didn't solve the problem. > > 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 (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
