[freetds] First select fails on newly created/populated table fails

Thompson, Bill D (London) ThompBil at exchange.uk.ml.com
Thu Apr 10 11:11:59 EDT 2003


All,

I've been having a look at  these issues, as well as some other small, but
significant  and annoying behaviours I have noticed with sqsh.

The upshot is that there are a number of behavioural differences between
sybase ct-library and our own, especially in the area of results processing.

The results processing got substantially re-worked in 0.61, and since then a
number of changes have gone in to improve our adherence to the exact
behaviours of Sybase db-library.
I am coming to the conclusion that a bit of an overhaul is necessary in the
ct-library results processing.

Our principle has always been to try and isolate the TDS protocol specifics
in the libtds libraries. 
Where possible we have also tried to build common generic functions in the
tds library that are called by each of the API libraries (db-library,
ct-library and odbc).

We have two generic functions of this type for results and row processing:

tds_process_result_tokens() & tds_process_row_tokens()

These are used by all 3 API's....

I have a good idea on how to alter the ct-library results processing so that
will behave exactly like Sybase's, but I am in a quandary as to what to do.
Essentially ct-library needs to get much closer to the actual TDS protocol
than the current generic functions allow.
It needs to do this to make the correct decisions about how to behave, what
to return to the calling program, and so on. 

I could :

Alter the behaviour of the generic functions so that ct-library can capture
the level of knowledge it requires about the TDS stream.
Unfortunately this would also mean changing the other API's , which AFAIK
don't currently have any problems in this area and are very stable.

Or I could :

Write some different results/row processing specially for ct-library either
as new functions within the tds library or in ct-library itself.
This has the obvious drawback of duplicate code, but safeguards the
db-library and odbc code from possible problems.

Any advice ?

Bill

> -----Original Message-----
> From:	Carl Edwards [SMTP:edwards at vitesse.com]
> Sent:	10 April 2003 00:44
> To:	FreeTDS Development Group
> Cc:	Brent Dooley
> Subject:	RE: [freetds] First select fails on newly created/populated
> table fails
> 
> I had a very similar problem doing a SELECT followed
> by an UPDATE using perl and DBI.
> 
> In .60 this was causing core dumps but in .61 it turned
> out that the first time it only executed the SELECT and
> each time after just the UPDATE???
> 
> I e-mailed the list a few times but never resolved 
> the problem, I eventually changed my SQL to just
> do one UPDATE.
> 
> Unfortunately I cannot make heads or tails of the
> return code from my $dbh->do("UPDATE ... so it is
> really hard to tell the difference between an error
> and a failed WHERE match.
> 
> Good luck,
> -Carl Edwards
> 
> 
> > -----Original Message-----
> > From: Richard Rowell [mailto:richard at bowmansystems.com]
> > Sent: Tuesday, April 08, 2003 12:21 PM
> > To: freetds at lists.ibiblio.org
> > Cc: Brent Dooley
> > Subject: [freetds] First select fails on newly created/populated table
> > fails
> > 
> > 
> > I create a table and insert rows into it.  The first time I 
> > do a select
> > the select returns nothing, not even the "0 rows affected" 
> > (even though
> > it should return two rows).  The exact same select repeated works the
> > second time and every time thereafter.  Snip for SQSH:
> > 
> > 1> create table ttest ( name varchar(50))
> > 2> insert into ttest values ( 'rick');
> > 3> insert into ttest values ( 'dave');
> > 4> go
> > 1> select * from ttest where name = 'rick'
> > 2> go
> > 1> select * from ttest where name = 'rick'
> > 2> go
> >  name                                              
> >  --------------------------------------------------
> >  rick                                              
> > 
> > (1 row affected)
> > 
> > I have played with this for the last two hours isolating it.  Here are
> > some observations I have made:
> > 1.  If you drop the where clause, it works as expected (the 
> > first time.)
> > 2.  If you drop the second go it works as expected.  
> > 3.  If you only do one insert instead of two it works as expected.  
> > 4.  Behaves the same with regular or temporary tables.
> > 5.  The exact same SQL works as expected when using Query 
> > Analyzer from
> > Windows 2k.  
> > 
> > I'm attaching the pertinent portion of the log file also.
> > 
> > Environment:
> > sqsh 2.1-5 (but it does the same thing under PHP4.2.3 which 
> > is where we
> > originally noticed it)
> > freetds/libct : 0.61-2 (Debian unstable)
> > Debian Testing/Unstable on i386
> > SQL Server 2000 Service Pack 2
> > 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds



More information about the FreeTDS mailing list