From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,89e2ed92b27de792 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news2.google.com!news.glorb.com!news2.glorb.com!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail Date: Sun, 27 Feb 2011 15:53:13 +0100 From: =?ISO-8859-1?Q?Thomas_L=F8cke?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Problem in GNATColl when using prepared queries: GNATCOLL.SQL.POSTGRES.GNADE.POSTGRESQL_ERROR is raised References: <4d67ce9c$0$23765$14726298@news.sunsite.dk> <1on2yzc25jxpr.1offs3nb41fqk$.dlg@40tude.net> <4d67f3db$0$23762$14726298@news.sunsite.dk> <1dbprbhut7js1.jeytwwyjsya4$.dlg@40tude.net> <4d682437$0$23760$14726298@news.sunsite.dk> <1v42jcu30zmag$.1xz86498g3zsm.dlg@40tude.net> In-Reply-To: <1v42jcu30zmag$.1xz86498g3zsm.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <4d6a6559$0$23761$14726298@news.sunsite.dk> Organization: SunSITE.dk - Supporting Open source NNTP-Posting-Host: 83.91.213.86 X-Trace: news.sunsite.dk DXC=k8X3^fP2R7Ce:i55N5G3eEYSB=nbEKnkK[R[7PZBi8oN1GQX8;5?CnGRED9SjB8:6IQo^8G8>AndMJZei]c:?jBET1MLbPdK;CD X-Complaints-To: staff@sunsite.dk Xref: g2news2.google.com comp.lang.ada:18597 Date: 2011-02-27T15:53:13+01:00 List-Id: On 2011-02-26 20:33, Dmitry A. Kazakov wrote: > 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." Here's the spec and comment for the Forward_Cursor type: type Forward_Cursor is tagged private; No_Element : constant Forward_Cursor; -- A cursor that iterates over all rows of the result of an SQL -- query. A single row can be queried at a time, and there is no -- possibility to go back to a previous row (since not all DBMS -- backends support this). -- This type automatically takes care of memory management and -- frees its memory when no longer in use. This type is tagged only -- so that you can override it in your own applications (an example -- is to add an Element primitive operation which converts the -- current row into a specific Ada record for ease of use). And then Has_Row: function Has_Row (Self : Forward_Cursor) return Boolean; -- Whether there is a row to process. Fetching all the results from -- a query is done in a loop similar to: -- Cursor := Execute (...) -- while Has_Row (Cursor) loop -- ... -- Next (Cursor); -- end loop; So seeing as you can't go back when using a Forward_Cursor, I'd say that the result-set is not cached. If there are any results available, the cursor simply points to the first row, and a call to Cursor.Next moves to the next row in the result-set. If you want to pre-fetch all the results, you'd instead use a Direct_Cursor: type Direct_Cursor is new Forward_Cursor with private; No_Direct_Element : constant Direct_Cursor; -- A direct cursor is a cursor that keeps all its results in -- memory, and gives access to any of the rows in any order. -- As opposed to a Forward_Cursor, you can iterate several times -- over the results. On the other hand, a direct_cursor uses more -- memory locally, so might not be the best choice systematically. Using that, you can freely move around in the result-set using various procedures. > 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 I've done some further digging, and it appears that GNATColl thinks the result is binary data when the query is prepared. When the same query is executed without preparing it, the data is returned just fine as Integer and String respectively. > > You should get the extended error code to determine the problem. There's no error code. The query is executed just fine on the RDBMS; it's GNATColl that fails at handling the result afterwards. So the only "error code" available is the raised exception I mentioned in my original post. I'll see if I can convince some of the other Ada-DK members to take a look at this very odd issue. Maybe we can do a debugging session at the next open Ada-DK meeting. That could be fun. :o) -- Thomas L�cke Email: tl at ada-dk.org Web: http//:ada-dk.org http://identi.ca/thomaslocke