FreeTDS Development Group

[Dan Mohn <mohnd AT egolfscore.com>]

Ok.  I created a .sql file as follows;

----------begin
DECLARE @Count int
declare @NamePrint nvarchar(255)
SET @Count = 0

DECLARE c1 cursor
FOR
SELECT Name
   from <database>.dbo.<tablename>

OPEN c1
FETCH NEXT FROM c1

WHILE @@fetch_status = 0 AND @Count < 4
BEGIN
        SET @Count = @Count + 1
        IF @Count > 2
        BEGIN
           PRINT 'You have 30 seconds to unplug the cable.'
           WAITFOR DELAY '00:00:30'
        END
        FETCH NEXT FROM c1 into @NamePrint
        PRINT '%' + @NamePrint + '%'

END
CLOSE c1

DEALLOCATE c1

GO
------------end

For the first test, I set the tds timeout to 10 seconds.  It timeouts
with the following message;

usr/local/freetds/bin/bsqldb -S <ipaddress> -U sa -P xxx -D dbname -i
timeouttest.sql
bsqldb: Msg 20003, Level 6
Adaptive Server connection timed out

bsqldb:193: dbsqlok() failed

Then, I set the freetds timeout to 100.  After starting the run, I wait
10 seconds, then unplug the network cable.  After 100 seconds, the
timeout occurs and I get the same message as above.

So it seems like freetds is timing out appropriately.  Is it possible
the messaging to the iodbc or realbasic layer is the problem?  Is there
a way I can test the odbc layer messaging somehow?

Thanks in advance.

Dan 

On Tue, 2007-04-10 at 23:47 -0400, James K. Lowden wrote:
> Dan Mohn wrote:
> >  I am physically
> > unplugging the network cable.  Like;
> >
> > send sql statement
> > while not resultset eof
> > ---here I pull the network cable after a couple of rows have been
> read
> > ---get data
> > ---check for an timeout error
> > ---get the next row
> > loop
> >
> > Interestingly, after appx 2 hours, an error is trapped, and
> Realbasic is
> > reporting the following error message it claims is from the odbc
> driver;
> >
> > [FreeTDS][<drivername>]Communication link failure.
> >
> > What do you recommend I do for my next step?
> 
> Hi Dan,
> 
> Could you please execute the same test in bsqldb?  I would like to
> know if
> the problem is in FreeTDS or in some higher layer.  That won't
> necessarily
> exculpate FreeTDS, but it will tell us if FreeTDS is at least
> internally
> consistent. 
> 
> --jkl
> 
>