Skip to Content.
Sympa Menu

freetds - Re: dg/ux challenges

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT umcc.ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: dg/ux challenges
  • Date: Sat, 25 Sep 1999 23:10:47 -0400 (EDT)



Eh, this looks exactly right.

For some reason tds_process_result_tokens() is getting called a third time
which blocks on the read(). The question is why.

insert this code in src/ctlib/ct.c (remove the old ct_results() and
recomment the other thing). It should print some info about how this is
called and give us some clues about what is going on.

Brian


CS_RETCODE ct_results(CS_COMMAND *cmd, CS_INT *result_type)
{
TDSRESULTINFO *resinfo;
int ret;

fprintf(stderr,"entering ct_results()\n");
tdsdump_log("%L inside ct_results()\n");
if (cmd->cmd_done) {
cmd->cmd_done = 0;
*result_type = CS_CMD_DONE;
return CS_SUCCEED;
fprintf(stderr,"ct_results() returning CS_SUCCEED res_type
= CS_CMD_DONE\n");
}
switch (ret = tds_process_result_tokens(cmd->con->tds_socket)) {
fprintf(stderr,"tds_proc_res_toks() returned %d\n",ret);
case TDS_SUCCEED:
resinfo = cmd->con->tds_socket->res_info;
if (resinfo->rows_exist) {
*result_type = CS_ROW_RESULT;
cmd->cmd_done = 1;
} else {
*result_type = CS_CMD_SUCCEED;
}
fprintf(stderr,"ct_results() returning CS_SUCCEED
res_type = %d\n",*result_type);
return CS_SUCCEED;
case TDS_NO_MORE_RESULTS:
*result_type = CS_CMD_DONE;
fprintf(stderr,"ct_results() returning
CS_END_RESULTS res_type = CS_CMD_DONE\n");
return CS_END_RESULTS;
case TDS_FAIL:
*result_type = CS_CMD_FAIL;
fprintf(stderr,"ct_results() returning CS_SUCCEED
res_type = CS_CMD_FAIL\n");
return CS_SUCCEED;
default:
fprintf(stderr,"ct_results() returning
CS_FAIL\n");
return CS_FAIL;
}
return CS_FAIL;
}

On Sat, 25 Sep 1999, Jeff Driscoll wrote:

> I followed your directions and this the content of client.out:
> len is 71
> 0:4
> 1:1
> 2:0
> 3:71 G
> 4:0
> 5:0
> 6:0
> 7:0
> 8:170
> 9:51 3
> 10:0
> 11:208
> 12:0
> 13:0
> 14:0
> 15:1
> 16:16
> 17:32
> 18:0
> 19:73 I
> 20:110 n
> 21:118 v
> 22:97 a
> 23:108 l
> 24:105 i
> 25:100 d
> 26:32
> 27:111 o
> 28:98 b
> 29:106 j
> 30:101 e
> 31:99 c
> 32:116 t
> 33:32
> 34:110 n
> 35:97 a
> 36:109 m
> 37:101 e
> 38:32
> 39:39 '
> 40:115 s
> 41:121 y
> 42:115 s
> 43:95 _
> 44:117 u
> 45:115 s
> 46:101 e
> 47:114 r
> 48:115 s
> 49:39 '
> 50:46 .
> 51:7
> 52:86 V
> 53:83 S
> 54:84 T
> 55:78 N
> 56:67 C
> 57:68 D
> 58:66 B
> 59:0
> 60:1
> 61:0
> 62:253
> 63:2
> 64:0
> 65:193
> 66:0
> 67:11
> 68:0
> 69:0
> 70:0
>
>
> On 09/22/99, "Brian Bruns <camber AT umcc.ais.org>" wrote:
> > Ok, looks like we have to do this the hard way. There is a line in token.c
> > in the tds_process_result_tokens() function that looks like this:
> >
> > /* get_incoming(tds->s); */
> >
> > You'll need to uncomment this line. Recompile and run sqsh. Don't change
> > the database as this function will then execute and we don't want that.
> > When you run your query (the sys_users thing), it'll go out to lunch but
> > it should generate a file called 'client.out' With that I should be able
> > to debug it enough to see what is going on.
> >
> > Oh, and you may need to link sqsh with the debug.c that is in the
> > freetds/samples directory as it has the get_incoming() function. So, you
> > would want to do something like:
> >
> > cd samples
> > gcc -g -c -o debug.o debug.c
> >
> > and then add /usr/src/freetds/samples/debug.o to the SYBASE_LIBS line in
> > sqsh's Makefile (where /usr/src/freetds is wherever freetds' source is on
> > your computer). Then relink sqsh.
> >
> > I warned you this was the hard way!
> >
> > BTW, I tested this against SQL 7.0 (no service pack) from Linux on Intel
> > and everything is fine. Smells like a change in SP1 to me.
> >
> > Brian
> >
>
> ---
> You are currently subscribed to freetds as: camber AT ais.org
> To unsubscribe, forward this message to $subst('Email.Unsub')
>
>





Archive powered by MHonArc 2.6.24.

Top of Page