freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
RE: [freetds] Help: MSSql/FreeTDS/Python now unstable
- From: Paul Rensing <paul.rensing AT att.net>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: RE: [freetds] Help: MSSql/FreeTDS/Python now unstable
- Date: 18 Mar 2003 11:55:50 -0500
James and others,
The Python Sybase driver uses the CT interface. I turned on debugging of
the Python driver in the place where it usually fails. I have attached
the output of the tracing.
The problem seems to be that, for the SQL query, occasionally it gets
back from ct_results() a status of CS_STATUS_RESULT, instead of the
usual CS_ROW_RESULT. After that it is very confused. If I immediately
repeat the same query, it works just fine.
I am still wondering if this could be a timing issue on the server end.
It only seems to fail after running my program for a while, and the
program adds data to the table I am looking at. Maybe the server is
still working on the previous inserts.
Any help is greatly appreciated.
Paul Rensing
On Mon, 2003-03-17 at 15:19, Lowden, James K wrote:
> > From: Paul Rensing [mailto:prensing AT cimetrics.com]
> > Sent: March 17, 2003 11:40 AM
> >
> > I modified my code a little to get more info. In the case you
> > cited, the
> > Python "description" table reports a single column (there should be 3)
> > with an empty description. Specifically it reports:
> > name ''
> > type_code 2
> > display_size 0
> > internal_size 4
> > precision 0
> > scale 0
> > null_ok 0
> >
> > Is it possible that this same bug exists in a different code path?
>
> I think it's very unlikely that we'd return 1 column of metadata where three
> exist; the bug was zero or all. It's possible we return a code that Python
> doesn't/shouldn't expect, causing it to cease collecting metadata earlier
> than it should. Or something else.
>
> Which API are we talking about, please? And can you reproduce the problem
> outside Python? We need to isolate the library and interface if we're going
> to locate the troublemaker. I know it's a nuisance, but I can't suggest
> anything better without breaking out gdb. After all, it's easy to prove the
> server sent the metadata; the question is, who dropped the ball and why?
>
> sqsh uses ct-lib; there are various odbc tools about. I don't have a
> general purpose db-lib exerciser, but I have a rudimenrary isql for db-lib
> that might suit your purpose.
--
Paul Rensing <paul.rensing AT att.net>
ct_command(cmd72, CS_LANG_CMD, "select max(StartTime) from Analyst."TEST"
where "Panel Name"='EB'", CS_NULLTERM, CS_UNUSED) -> CS_SUCCEED
ct_send(cmd72) -> CS_SUCCEED
ct_results(cmd72, &result) -> CS_SUCCEED, CS_STATUS_RESULT
ct_res_info(cmd72, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 1
_row_bind: status, num_cols 1 1
cmd = <CommandType object at 0x81749e8>
ct_describe(cmd72, 1, &fmt) -> CS_SUCCEED, datafmt394=[name:""
type:CS_INT_TYPE status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:4
scale:0 precision:0]
ct_bind(cmd72, 1, &datafmt394->fmt=[name:"" type:CS_INT_TYPE status:CS_FALSE
format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0],
databuf394->buff, databuf394->copied, databuf394->indicator) -> CS_SUCCEED,
databuf394
ct_fetch(cmd72, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> CS_SUCCEED, 1
Driver bug: got '0' from time query on GP_ScottsdaleHilton_Energy_TEST_sFT
(trial 0)
Description: [('', 2, 0, 4, 0, 0, 0)]
ct_cancel(NULL, cmd72, CS_CANCEL_ALL) -> CS_SUCCEED
ct_cmd_drop(cmd72) -> CS_SUCCEED
****retry****
ct_command(cmd73, CS_LANG_CMD, "select max(StartTime) from Analyst."TEST"
where "Panel Name"='EB'", CS_NULLTERM, CS_UNUSED) -> CS_SUCCEED
ct_send(cmd73) -> CS_SUCCEED
ct_results(cmd73, &result) -> CS_SUCCEED, CS_ROW_RESULT
ct_res_info(cmd73, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 1
_row_bind: status, num_cols 1 1
cmd = <CommandType object at 0x8325d48>
ct_describe(cmd73, 1, &fmt) -> CS_SUCCEED, datafmt395=[name:""
type:CS_DATETIME_TYPE status:CS_CANBENULL format:CS_FMT_UNUSED count:1
maxlength:8 scale:0 precision:0]
ct_bind(cmd73, 1, &datafmt395->fmt=[name:"" type:CS_DATETIME_TYPE
status:CS_CANBENULL format:CS_FMT_UNUSED count:1 maxlength:8 scale:0
precision:0], databuf395->buff, databuf395->copied, databuf395->indicator) ->
CS_SUCCEED, databuf395
ct_fetch(cmd73, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> CS_SUCCEED, 1
success
ct_cancel(NULL, cmd73, CS_CANCEL_ALL) -> CS_SUCCEED
ct_cmd_drop(cmd73) -> CS_SUCCEED
-
[freetds] Help: MSSql/FreeTDS/Python now unstable,
Paul Rensing, 03/17/2003
- <Possible follow-up(s)>
-
RE: [freetds] Help: MSSql/FreeTDS/Python now unstable,
Lowden, James K, 03/17/2003
- RE: [freetds] Help: MSSql/FreeTDS/Python now unstable, Paul Rensing, 03/17/2003
-
RE: [freetds] Help: MSSql/FreeTDS/Python now unstable,
Lowden, James K, 03/17/2003
- RE: [freetds] Help: MSSql/FreeTDS/Python now unstable, Paul Rensing, 03/18/2003
- RE: [freetds] Help: MSSql/FreeTDS/Python now unstable, Lowden, James K, 03/18/2003
Archive powered by MHonArc 2.6.24.