FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il mar, 2004-01-27 alle 18:46, Peter Deacon ha scritto:
> On Tue, 27 Jan 2004, ZIGLIO, Frediano, VF-IT wrote:
> 
> > About this change:
> > http://cvs.sourceforge.net/viewcvs.py/freetds/freetds/src/odbc/odbc.c?r1
> > =1.291&r2=1.292&sortby=date
> 
> > I don't really understand the problem and I don't think change is
> > correct...
> 
> > The only reason SQLDescribeCol should fail with former code is when we
> > fetched all results, however why SQLDescribeCol should success in this
> > situation? Peter state that this was caused by a empty rowset with a
> > numeric but looking at the code and doing some tests do not help
> > (problem do not occur).
> > current_statement is used to store current statement, if statement is no
> > more active it's nosense to still retain old statement. Also issuing
> > another query on another statement cause current_statement to change so
> > SQLDescribeCol on first statement fails too.
> > A better workaround would be to comment these lines in SQLDescribeCol:
> 
> I can pretty much reproduce this one at will again, it seems to like
> something in my environment... Trying to isolate by calling test queries
> hasn't worked so well for me but this definately fixes my problem.
> 

A ODBC trace would be fine...

> I'm not sure 'when' SQLDescribe col is expected not to work (I assume
> until you move on to another statement or free/reset the statement handle,
> my docs don't mention this explicitly) but to me it seems if SQLExec
> processes TDS_NO_MORE_RESULTS and there is column information, you should

TDS_NO_MORE_RESULTS means you processed all results (so DONE, ROWFMT,
etc) however if there are column (ROWFMT results) this mean that a DONE
with count (and/or errors) follows so you stop at DONE... I really don't
understand...

Well.... wait a moment...

$ export TDSDUMP=out.txt
$ ./tsql -Slocal -Usa
locale is "it_IT.UTF-8"
locale charset is "UTF-8"
Password:
Msg 2409, Level 11, State 2, Server , Line 1
Cannot find the requested character set in Syscharsets:  name = 'utf8'.
 
Msg 2411, Level 10, State 1, Server , Line 1
No conversions will be done.
 
1> set nocount on
2> go
1> create table #tmp1 (i int)
2> insert into #tmp1 values(123)
3> select * from #tmp1
4> go
i
123
1> bye

$ less out.txt
...
21:16:19.823931 tds_process_result_tokens() state is COMPLETED
Sending packet @ 21:16:48.233590
0000 0f 01 00 5b 00 00 00 00-21 4e 00 00 00 00 63 72 |...[.... !N....cr|
0010 65 61 74 65 20 74 61 62-6c 65 20 23 74 6d 70 31 |eate tab le #tmp1|
0020 20 28 69 20 69 6e 74 29-0a 69 6e 73 65 72 74 20 | (i int) .insert |
0030 69 6e 74 6f 20 23 74 6d-70 31 20 76 61 6c 75 65 |into #tm p1 value|
0040 73 28 31 32 33 29 0a 73-65 6c 65 63 74 20 2a 20 |s(123).s elect * |
0050 66 72 6f 6d 20 23 74 6d-70 31 0a                |from #tm p1.|

Received header @ 21:16:48.306902
0000 04 01 00 3a 00 00 00 00-                        |...:....|

Received packet @ 21:16:48.306958
0000 fd 01 00 02 00 00 00 00-00 fd 01 00 02 00 01 00 |........ ........|
0010 00 00 ee 0b 00 01 00 01-69 10 07 00 00 00 38 00 |........ i.....8.|
0020 ae 01 00 00 d1 7b 00 00-00 fd 00 00 02 00 01 00 |.....{.. ........|
0030 00 00                  -                        |..|
...

!!! no count and rows !!! Bingo !!! I think this was the real problem.
We should stop even if we have no COUNT and/or error


> be allowed to call SQLDescribeCol to retreive that information even if
> there is no data... since the column information could still be useful to
> the application.  Resetting current_statement too early (Inside SQLExec)
> pretty much guarantees that won't happen :(
> 
> The first thing I tried doing was to modify ODBCDescribe but that idea as
> it didn't follow the spirit of how current_statement seemed to have been
> being used.
> 
> Have Fun!
> Peter
> 
> >     if (stmt->dbc->current_statement != stmt) {
> >             odbc_errs_add(&stmt->errs, "24000", NULL, NULL);
> >             ODBC_RETURN(stmt, SQL_ERROR);
> >     }
> >     IRD_CHECK;
> >
> > so SQLDescribeCol return data from IRD without any check.
> > Naturally it would be better to understand the real problem... why and
> > when does SQLDescribeCol fail??
> >

Another issue: SQLDescribeCol should return error 24000 or another error
(there is no column specified?). 

Attached a patch, I hope it works for you...

freddy77

Attachment: vedi.diff.gz
Description: GNU Zip compressed data