Tom:

With all due respect, what do our friends at MBFoster have to say? I was a
customer of theirs for a number of years and they would usually take a look
at the query and make a determination (fixed, patch ##, here, you can have
it) or isolate the problem to another source, i.e. not the ODBC.

Just a thought, I found their support to be first rate, and, no, I am not a
paid informant(!).....

JP in Sacto

-----Original Message-----
From: Emerson, Tom [mailto:[log in to unmask]]
Sent: Thursday, July 29, 2004 4:21 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] ODBC limitation? [length of query string]


Previously I noted:

> I wrote a quick test
> when the entries in the list reach 127, the retrieval time
> suddenly jumps to 80+ seconds!

after "scrambling" the entries to ensure that the 128th item was different,
I was able to repeat the results:

  <=127 items: 4 seconds to retrieve the data
  >=128 items: 78 seconds!

Originally, I was selecting the list of "keys" via the query

    select distinct <key> from <set>

where in this case "set" ends up being the target of the second query
mentioned earlier in the thread [i.e., I'm getting a list of "guaranteed
hits" from the database]  Because of the "distinct", the results (should
be?) ordered, so to "scramble" the entries I appended every 4th record
[i.e., performed three extra "movenext" operations on each iteration], to be
absolutely certain, I also did a movelast and then "moveprev" within the
loop [i.e., read the chain backwards]

same every time -- 128+ "matching" entries and the query time jumped from 4
seconds to about 80 seconds.

If nothing else, I certainly have an "upper bound" on a chunk-size to work
with :)

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *