FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Trælnes AS
> Sent: Tuesday, November 15, 2005 11:13 AM
> 
> 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).
> 
> 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)]

Yes.

> 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....?

It's a little odd.  When the tds library hits a problem like that, it 
normally produces a message 20019:

        "Attempt to initiate a new SQL Server operation with results pending."

Such messages are logged always in 0.63 and are logged in the snapshot if 
'debug flags' in freetds.conf includes 0x80 (the default).  (Memo to file: 
make sure the debug mask is mentioned at the top of the TDSDUMP log.)

Your log doesn't include such a message.  Perhaps the DM detected the problem 
before passing it to FreeTDS.  

> 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....)

The client application.  It's not a matter of threading; it's a matter of the 
design of the TDS protocol and the of the server.  Cf. 
http://www.freetds.org/faq.html#pending.

I think for the moment you're stuck.  :-(

Regards, 

--jkl

-----------------------------------------
The information contained in this transmission may be privileged and
confidential and is intended only for the use of the person(s) named
above. If you are not the intended recipient, or an employee or agent 
responsible
for delivering this message to the intended recipient, any review, 
dissemination,
distribution or duplication of this communication is strictly prohibited. If 
you are
not the intended recipient, please contact the sender immediately by reply 
e-mail
and destroy all copies of the original message. Please note that we do not 
accept
account orders and/or instructions by e-mail, and therefore will not be 
responsible
for carrying out such orders and/or instructions.  If you, as the intended 
recipient
of this message, the purpose of which is to inform and update our clients, 
prospects
and consultants of developments relating to our services and products, would 
not
like to receive further e-mail correspondence from the sender, please "reply" 
to the
sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New 
York,
NY 10105.