FreeTDS Development Group

[Trælnes AS <post AT traelnes.no>]

Frediano Ziglio wrote:
> Il giorno sab, 12/11/2005 alle 23.39 +0100, Trælnes AS ha scritto:
> > 
> > [ODBC][9136][SQLExecute.c][354]
> >                 Exit:[SQL_ERROR]
> >                 DIAG [24000] [FreeTDS][SQL Server]Invalid cursor state
> 
> This can be caused by application trying do use 2 active statement on
> same connection (like a select and an update together) or if application
> do not close correctly statement (not getting all data).

If you can reproduce the problem with a limited test, a TDSDUMP log will
show whether or not your application is making the mistakes Frediano
cites.  

Thanks for your response.

1. It looks like it could be 2 active statements since in the unixODBC log
there are 2 statements just after each other and the error happens right
after that>

[ODBC][2715][SQLPrepare.c][180]
                Entry:
                        Statement = 0x8133988
                        SQL = [SELECT * FROM RealTimeSipBuddies WHERE name =
?][length = 47 (SQL_NTS)]
[ODBC][2715][SQLAllocHandle.c][872]
                Exit:[SQL_SUCCESS]
                        Output Handle = 0x8213d88
[ODBC][2715][SQLPrepare.c][180]
                Entry:
                        Statement = 0x8213d88
                        SQL = [SELECT * FROM RealTimeSipBuddies WHERE name =
?][length = 47 (SQL_NTS)]


2. I reproduced the problem and I got a TDSDUMP. But for it seems to be ok,
I cannot see anything wrong here. But also I see a lot I do not
understand... Can maybe someone have a quick look at the log file attached?
I also find it to be strange that in the TDSDUMP I cannot find 24000 or
"Invalid cursor state" or other messages that I find in the unixODBC
log....?

3. If it is so that there are 2 active statements on same connection would
the problem then be in unixODBC (it doesn't handle threads?) or in the
client application? (which in this case is Asterisk....)

Best regards,
Marius

Attachment: freetds.log.3.zip
Description: Zip compressed data