Skip to Content.
Sympa Menu

freetds - Re: [freetds] Unable to query MSSQL server using freetds

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Unable to query MSSQL server using freetds
  • Date: Tue, 5 Oct 2010 11:00:46 +0200

2010/10/1 Frediano Ziglio <freddy77 AT gmail.com>

>
>
> 2010/9/30 Frediano Ziglio <freddy77 AT gmail.com>
>
>
>>
>> 2010/9/28 Belden, Alvin (H USA) <alvin.belden AT siemens.com>
>>
>> Hi All,
>>>
>>> We are trying to port our applications that currently use Ct Lib/Sybase
>>> to Sql Server using the Ct lib supplied by FreeTds. We are able to connect
>>> to and switch databases but fail to query. We're running the following
>>> versions:
>>>
>>> Linux (application (C++) server) - Red Hat Enterprise Linux Server
>>> release 5.4 (Tikanga)
>>> FreeTds - 082
>>> MSSQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)
>>>
>>> The problem with the query seems to be (from the dump below) that the
>>> single parameter to stored procedure get_users_info, being passed as
>>> RADRAD
>>> is truncated to RADR. I have tried different parameter strings but
>>> whatever
>>> I pass appears from the dump to be truncated and therefore returns
>>> nothing.
>>> I have also tried making the parameter larger than the actual field in the
>>> table in the hope that the truncation would result in a match. Running in
>>> Isql, I can run the same stored procedure and it works fine.
>>>
>>> Below is the tdsdump running from a C++ application. After that, is the
>>> dump running the same stored proc from Isql. Appreciate any help.
>>>
>>>
>>>
>> ...
>>
>>
>>> token.c:2232: rows_affected = 0
>>> util.c:110:logic error: cannot change query state from IDLE to PENDING
>>> ct.c:1157:ct_results() process_result_tokens returned 1 (type 4052)
>>> ct.c:1262:ct_results() results state = 0
>>> ct.c:1263:ct_results() command type = 148
>>> ct.c:1264:ct_results() dynamic cmd = 0
>>> ct.c:1100:ct_results()
>>> ct.c:682:ct_command()
>>> ct.c:215:setting command state from SENT to IDLE
>>> ct.c:215:setting command state from IDLE to IDLE
>>> ct.c:766:ct_command() added rpcname "get_users_info"
>>> ct.c:215:setting command state from IDLE to READY
>>> ct.c:3358:ct_param()
>>> ct.c:3359:ct_param() data addr = 0xbfdd29fe data length = 6
>>> ct.c:4324: _ct_fill_param() status = 256
>>> ct.c:2003:_ct_get_server_type(0)
>>>
>>
>> type == 0 ?? could you send some source code that calls ctlib ??
>>
>>
>>> ct.c:3390: ct_param() added rpc parameter @user_init
>>> ct.c:844:ct_send() command_type = 149
>>> ct.c:4239:paraminfoalloc: status = 256, maxlen 0
>>> ct.c:4240:paraminfoalloc: name = @user_init, varint size 2 column_type 47
>>> size 6, 6 column_cur_size 6 column_output = 0
>>> ct.c:4079:paramrowalloc, size = 6, data = 0xa4cb450, row_size = 0
>>> mem.c:563:tds_free_all_results()
>>> util.c:162:Changed query state from IDLE to QUERYING
>>> query.c:1292:tds_put_data_info putting param_name
>>> query.c:1326:tds_put_data_info putting status
>>> query.c:1420:tds_put_data: colsize = 6
>>> query.c:1449:tds_put_data: not null param varint_size = 2
>>> util.c:162:Changed query state from QUERYING to PENDING
>>> net.c:779:Sending packet
>>> 0000 03 01 00 4e 00 00 01 00-0e 00 67 00 65 00 74 00 |...N.... ..g.e.t.|
>>> 0010 5f 00 75 00 73 00 65 00-72 00 73 00 5f 00 69 00 |_.u.s.e. r.s._.i.|
>>> 0020 6e 00 66 00 6f 00 00 00-0a 40 00 75 00 73 00 65 |n.f.o... .@.u.s.e|
>>> 0030 00 72 00 5f 00 69 00 6e-00 69 00 74 00 00 af 06 |.r._.i.n .i.t....|
>>> 0040 00 09 04 d0 00 34 06 00-06 00 52 41 44 52 |.....4.. ..RADR|
>>>
>>>
>> is not truncated, it seems garbled. Instead of "RADRAD" it sends "RADR"
>> with 2 bytes (06 00) before.
>>
>>
>
> From ct_param documentation
>
> If *datatype* is CS_VARCHAR_TYPE or CS_VARBINARY_TYPE then *data* must
> point to a CS_VARCHAR or CS_VARBINARY structure
>
> so we don't support correctly CS_VARCHAR_TYPE and CS_VARBINARY_TYPE...
>
>
Just committed a patch which fixes this issue.

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page