Re: Problem in GNATColl when using prepared queries: GNATCOLL.SQL.POSTGRES.GNADE.POSTGRESQL_ERROR is raised

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 25 Feb 2011 19:24:27 +0100, Thomas L�cke wrote:

> On 2011-02-25 17:05, Dmitry A. Kazakov wrote:
>> I don't understand your code, in particular where the statement prepared is
>> actually executed?
> 
>     Cur.Fetch (Connection => Connection,
>                Stmt       => P,
>                Params     => (1 => +Some_Name'Access));
> 

That does not look like an execution of the statement P. I would expect
fetch rather walking through the result set than executing anything. But I
don't know GNATColl.

>> Where the cursor gets closed? DBMS does not appreciate
>> cursors left unclosed. Does GNATColl maintain cursor states internally?
> 
> Yes.

Does it that right? I am asking this, because it is an issue in ODBC, where
the cursor state depends on many factors and that the same sequence of
calls may either close the cursor or not depending on the operation
outcome.

> > Why
> > fetch is not called within a loop?
>
>    while Cur.Has_Row loop
>       Put_Line ("id=" & Cur.Integer_Value (0)'Img);
>       Put_Line ("name=" & Cur.Value (1));
>       Cur.Next;
>    end loop;

What is the semantics of Has_Row does it refer the current row or that Next
would not fail when called?

>> I can only stress that you will
>> never get it working with literal values. I've been there. It isn't worth
>> to try.
> 
> I don't want it to work with literal values. I want it to work with
> prepared and parameterized queries. I simple show an example with
> literal values because that actually works.  :o)
> 
> The problem is that GNATColl dumps an exception when I try to use
> prepared and parameterized queries.

That means that you are doing something wrong. Bound values must work.

> I like GNATColl's interface.

OK

>> [ At least ODBC has tracing mode, which sometimes with some drivers indeed
>> traces. So that you could see the actual statement. ]
> 
> GNATColl has that too. There's nothing wrong with the actual statement.
> The problem occurs when I try to extract the data in the loop using
> these two calls:
> 
>     Cur.Integer_Value (0)
>     Cur.Value (1)

Tracing usually tells if the result does not contain requested columns,
the values cannot be converted, the cursor is wrong etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de