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 22:50:47 +0100, Thomas L�cke wrote:

> On 2011-02-25 21:08, Dmitry A. Kazakov wrote:

>>>     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'm not quite sure I understand what you mean Dmitry. Could you elaborate?

Does execution of the statement pre-fetches the first row? Traditionally
the semantics of such stuff rather refers to the following row, like when
file reading:

   while not EOF (File) loop
       -- No line read yet, EOF refers to the next one
       Read_Line (File, ...);
   end loop;

I.e. is Has_Row "there is another row to fetch", or "the row is already
fetched and column values are cached."

>> That means that you are doing something wrong. Bound values must work.
> 
> Exactly. And that part does work. I can see in the trace that the query
> is correct, and I can see it executed perfectly in the PostgreSQL log.
> 
> The problem occurs _after_ the query has been executed. Things go bad
> when I try to extract the data, and it only fails when I'm using a
> prepared and parameterized query, re. my original post:
> 
>     If I get rid of the Cur.Integer_Value (0) and Cur.Value (1) calls
>     in the while loop from the prepared example, then I also get rid
>     of the exception, so it appears to be some sort of issue with the
>     *Value functions and prepared queries.
> 
> I'm pretty sure this is a bug somewhere in GNATColl.

Possible reasons:

1. Value conversion failed
1.1. type is wrong
1.2. address is broken
1.3. alignment is illegal
1.4. no value
1.5. constraint error

2. The requested column number is wrong

3. The cursor is wrong

You should get the extended error code to determine the problem.

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