Thanks for your suggestions. I did move the code to create the commands and add the parameters in a sub that I call from the Load sub. That improved the response time considerably. I should have caught that earlier but did not know about the prepare phase. Definitely better than what it was before.
I'm taking an online class on Stored Procedures. The ones that I have written always return a data set, then I perform a Read and if successful, I retrieve the values from the reader object. I realize that may not be the best way. I do appreciate your input.
Thank you,
Antonio Mira
Application Developer - Mid-Ohio Division
Time Warner Cable
1015 Olentangy River Road - 2nd Floor
Columbus, OH 43212
http://www.timewarnercable.com
phone: 614 827 7949
-----Original Message-----
From: systemidotnet-bounces@xxxxxxxxxxxx [mailto:systemidotnet-bounces@xxxxxxxxxxxx] On Behalf Of ibm
Sent: Thursday, May 28, 2009 8:55 AM
To: .net use with the System i
Subject: Re: [SystemiDotNet] Validating data...
Can you post the SP code? I agree to have an OUT param on the SP.
-----Original Message-----
From: systemidotnet-bounces@xxxxxxxxxxxx
[mailto:systemidotnet-bounces@xxxxxxxxxxxx] On Behalf Of Walden H.
Leverich
Sent: Wednesday, May 27, 2009 4:42 PM
To: .net use with the System i
Subject: Re: [SystemiDotNet] Validating data...
My recollection is that the iDB2Command does a prepare round trip before
the first use, and since you're recreating the command on every
invocation that's a lot of round trips. Can you move the definition of
the command into a common place and then just set the parm values once
for each invocation. In essence invoking the same instance each time.
Also, why have a data reader and return a result set, that's a lot
heaver than just having a third output parameter on the sproc. And I
don't see where you're defining cn, I assume you're either not opening
it each time, or you're relying on connection pooling, yes?
-Walden
midrange.com
