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,ee0dc912649d50d4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!meganewsservers.com!feeder2.on.meganewsservers.com!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada DB bindings and APQ References: <1km3c584awura$.y7djkir1ozya$.dlg@40tude.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <_%6wd.154$jT5.98@read1.cgocable.net> Date: Wed, 15 Dec 2004 22:10:49 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1103166586 24.150.168.167 (Wed, 15 Dec 2004 22:09:46 EST) NNTP-Posting-Date: Wed, 15 Dec 2004 22:09:46 EST Organization: Cogeco Cable Xref: g2news1.google.com comp.lang.ada:6987 Date: 2004-12-15T22:10:49-05:00 List-Id: Brian May wrote: >>>>>>"Brian" == Brian May writes: > > > Brian> The documentation has an alternative loop structure: > > Brian> while not End_Of_Query(Q) loop Fetch(Q); ... end loop; > > I realized, despite the documentation, End_Of_Query is not currently > supported on sequential connections, because it is not known if all > tuples have been fetched until you try to fetch the next one past the > end. Actually for PostgreSQL, this works fine. But for MySQL (at least for versions that I worked with), it was "MySQL busted" (this is documented in the APQ 2.2 manual). MySQL's library would first indicate that it is "not at end", and then when you went to fetch a row, it would realize "whoopsie, we are at the end of rows". Then when I got to Sybase (IIRC), you cannot do this kind of test at all in sequential mode. > This limitation could be overcome if the previous call to the > "execute" or "fetch" called fetch in advance for the next row, and > stored the results in a temporary holding point. You don't miss out on > anything either, as all the rows will eventually have to be fetched > anyway. Prefetching introduces much ugliness in the Query_Type object, because you change the state of things. This can be especially complicated for Sybase, because the Sybase is very fussy about what happens on the connection and its state(s). Based upon what I've seen so far, I would _not_ recommend any kind of prefetching. > This is better, IMHO, then requiring an exception be the terminating > condition for a loop. I'll agree that I am not completely happy with the way that Fetch raises the exception, but I felt that was better than the possibility of ignoring a failure (the C tendancy). That way if you code a SELECT for example that should only return 1 row, but you get zero rows for some reason, a Fetch would raise an exception (it cannot be ignored without going out of your way!) The other consideration is that normally many rows are fetched, and there is only one "End". In this scenario, I felt that the exception was an acceptable compromise. > An alternative would be to restructure the loop as: > > while true loop > Fetch(Q); > exit if No_More_Data(Q); > > ... > end loop; > > I don't particular like this approach though, although it would work. I like the neatness of this approach, but the danger is that you might do the "..." part on a row that might not exist. Though I suppose the Query_Type object could maintain enough state such that it can raise an exception if any "Values" were fetched from the row that is not there. Just a quibble: I'd prefer something like "No_Row(Q)" perhaps. An even neater loop is this, IMHO ;-) > loop > Fetch(Q); > exit when No_More_Data(Q); > > ... > end loop; -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg