Fwd: [unixODBC-support] PHP PDO unixODBC FreeTDS SQL Server text column size

Jochen Daum <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <CAPeqxCfcwGZqAy_xCL405jWoA9eO3_GD8w_9GiSbT_5YN-BmZA@mail.gmail.com>
Hi,

I am investigating an issue whereby an empty column is returned for a
text field when using PHP PDO unixODBC FreeTDS SQL Server.

I'm running Ubuntu 12.04 and my FreeTDS file is as here

/etc/freetds/freetds.ini

# Global settings are overridden by those in a database
# server specific section
[global]
        # TDS protocol version

        # Whether to write a TDSDUMP file for diagnostic purposes
        # (setting this to /tmp is insecure on a multi-user system)
        dump file = /tmp/freetds.log
        dump file append
        debug flags = 0xffff

        # Command and connection timeouts
;       timeout = 10
;       connect timeout = 10

        # If you get out-of-memory errors, it may mean that your client
        # is trying to allocate a huge buffer for a TEXT field.
        # Try setting 'text size' to a more reasonable limit
        client charset = UTF-8
        tds version = 8.0
        text size = 10971520
        port = 1433


As per below from the unixODBC mailing list, it appears my restriction
is at the driver (=freetds) level.

I also found this:
http://yahowto.blogspot.co.nz/2011/01/fix-ntext-problems-with-php-freetds.html,
but changing the column from text to varchar(max) did not help.

Any idea how to diagnose this. I also seem to have no FreeTDS logging.

Thanks for any help,

Jochen


---------- Forwarded message ----------
From: Nick Gorham <[email protected]>
Date: 24 September 2012 11:10
Subject: Re: [unixODBC-support] PHP PDO unixODBC FreeTDS SQL Server
text column size
To: Support for the unixODBC project <[email protected]>


On 21/09/12 10:14, Jochen Daum wrote:
>
> Hi again,
>
> with odbc Trace enabled I see now that the size of the text column
> that doesn't work is restricted to 4096 bytes, at least this is how I
> interpret the log:
>
> Column Name = [attaContent]
>                          Data Type = 0x7fbf7136d618 -> -1
>                          Column Size = 0x7fff8c0d11d4 -> 4096
>                          Decimal Digits = NULLPTR
>                          Nullable = NULLPTR
> [ODBC][29384][1348216767.780752][SQLColAttribute.c][286]
>                  Entry:
>                          Statement = 0x7fbf712a2580
>                          Column Number = 6
>                          Field Identifier = SQL_DESC_DISPLAY_SIZE
>                          Character Attr = (nil)
>                          Buffer Length = 0
>                          String Length = (nil)
>                          Numeric Attribute = 0x7fff8c0d11d8
> [ODBC][29384][1348216767.780768][SQLColAttribute.c][657]
>                  Exit:[SQL_SUCCESS]
>
Well, the driver is reporting that the column is 4096 bytes long, and
is a SQL_LONGVARCHAR.

>
> Is there a setting to control the maximum number of bytes returned. I
> think I have these right in php.ini:
>
> odbc.defaultlrl = 10000000
>
> (also have
> mssql.textlimit = 2147483647
>
> ; Valid range 0 - 2147483647.  Default = 4096.
> mssql.textsize = 2147483647
>
> but this shouldn't matter, correct?)

No, the driver is reporting the column size, setting PHP variables
wont change the driver.

--
Nick
_______________________________________________
unixODBC-support mailing list
[email protected]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support


-- 
P.S.: Latest newsletter: Website application reporting - an overview -
http://eepurl.com/pKrAD

Kind Regards,

Jochen Daum

"There is no shortcut to anywhere worth going" - Beverly Sills

Automatem Ltd
Phone: +64 9 630 3425
Mobile: +64 21 567 853
Email: [email protected]
Website: www.automatem.co.nz
Skype: jochendaum
http://nz.linkedin.com/in/automatem
http://twitter.com/automatem
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.