.odbc.eval not returnning full result.

Hello:
    I encounter this problem after upgrade freetds protocol  from 4.2 to 7.1

q)count m : ex “select merchant_id from merchant”

116718

q)count ex “select * from merchant”

62070

where ex: .odbc.eval[handle], and handle is the odbc handle returned by open.

Switch to TDS_Version=4.2 in the connection string has no problem.

according to this url:

http://www.freetds.org/userguide/troubleshooting.htm

Text Fields

Questions sometimes arise over large varchar types (anything larger than varchar(255)) that became available with Microsoft SQL Server 7.0. When accessing long varchars with TDS protocol version 4.2 or 5.0, these fields will be truncated to 255 characters, due to limitations inherent in the protocol definition. Your best bet in that case is to convert them to text types.

It seemed that q is run out of memory, but: (, added by me)

q).Q.w

used| 1,171,984

heap| 201,326,592

peak| 201,326,592

wmax| 0

mmap| 0

mphy| 16,783,630,336

syms| 910

symw| 34451

It seemed that memory should not be an issue.

I tried to add FreeTDS log, but it will take forever.

Any help? 

Thanks in advance.

I figured it out myself.
I noticed that it always return the same number of rows, then I find the next row that cause problem.

Then I use binary search to find the column that cause the trouble from 110 columns. 

q)ex “select MERCHANT_NAME from merchant where merchant_id = 185730”

more

MERCHANT_NAME


q)ex “select MERCHANT_id from merchant where merchant_id = 185730”

MERCHANT_id


185730     

using tsql, I’m able to find the error:

1> select merchant_name from merchant where merchant_id = 185730;

2> go

merchant_name

Error 2403 (severity 4):

        Some character(s) could not be converted into client’s character set.  Unconverted bytes were changed to question marks (‘?’)

So the problem is odbc lib silently ignored above error. Can this be fixed?

meaning while, I’ll try to figure out a good character set for FreeTDS.

Happy hacking!