As long as it performs then you’re golden.
Nothing like testing the heck out of it. Especially if it’s a regular query.
Regards,
[
http://static.helpsystems.com/hs/email/templates/signatures-final/images/hs-logo2.png]
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx<mailto:richard.schoen@xxxxxxxxxxxxxxx>
p. 952.486.6802
w. helpsystems.com<
http://www.helpsystems.com/>
[cid:image002.jpg@01D1A545.4C2BF250]<
http://www.linkedin.com/in/richardschoen>[cid:image003.jpg@01D1A545.4C2BF250]<
http://www.twitter.com/richardschoen>
From: Spencer Elliott <spencer@xxxxxxxxxxxxxx>
Sent: Monday, April 8, 2019 9:57 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Cc: Richard Schoen <Richard.Schoen@xxxxxxxxxxxxxxx>
Subject: Re: Maximum OBDC Query Size
Hi Richard,
The actual issue boils down to speed. Which is faster? A single select with a large result set that is processed by the program or a bunch of selects with a small result set. I chose the single select approach. It just seems to me that it would be faster than 500 selects and 500 open cursor, close cursor ect.
Spencer C Elliott
949-366-5234 X152 (O) l (949) 544-1237 (Skype)
Spencer@xxxxxxxxxxxxxx<mailto:Spencer@xxxxxxxxxxxxxx>
[
https://lh5.googleusercontent.com/If7iuZEwwjYu9oznigmki-_w-lecjSjX3BpMcyuH5JAgJAfALevN3IvzHEVoAJD1Xbd1wpyxpuPG8fjp3qBx1UETCfw2Kmk_IHSKpaTy4k20J90o-NnyrAkK_IGeupgn0t6SZ6HJaY2z7GPzNg]
www.s4isystems.com<
http://www.s4isystems.com>
Follow us:
[Follow_us][Follow_us][Follow_us][Follow_us][Follow_us]
NOTE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and destroy all copies of the original message.
On Mon, Apr 8, 2019 at 7:42 AM Richard Schoen via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>> wrote:
Yeah I realized that once I re-read the question 😊
Looks like what you've discovered should give you enough runway unless you've had an issue with running your large statement.
One option to consider might be to call an RPG program that contains the SQL and return a resultset for processing from the RPG app perhaps.
Seems like this might be a good use case for some pre-processing on the IBMi to a temp table, but I don't know enough about the actual business case.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx<mailto:richard.schoen@xxxxxxxxxxxxxxx>
p. 952.486.6802
w. helpsystems.com<
http://helpsystems.com>
------------------------------
message: 3
date: Mon, 8 Apr 2019 07:01:31 -0700
from: Spencer Elliott <spencer@xxxxxxxxxxxxxx<mailto:spencer@xxxxxxxxxxxxxx>>
subject: Re: Maximum OBDC Query Size
Hi Richard,
The question was about how big can a SQL statement be when submitted through ODBC NOT how big can the result set be. I am working on a project where I need to submit an extremely large SQL statement (in my opinion,
10k+) to the IBM i with a very large WHERE (500+ predicates) clause.
Spencer C Elliott
949-366-5234 X152 (O) l (949) 544-1237 (Skype)
Spencer@xxxxxxxxxxxxxx<mailto:Spencer@xxxxxxxxxxxxxx>
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx<mailto:support@xxxxxxxxxxxx> for any subscription related questions.
Help support midrange.com<
http://midrange.com> by shopping at amazon.com<
http://amazon.com> with our affiliate link:
https://amazon.midrange.com
As an Amazon Associate we earn from qualifying purchases.