Re: Node.js result set question - Trimming blanks

[Aaron Bartell <aaronbartell@xxxxxxxxx>]

Not sure if there is reasoning from IBM behind that, but I agree, it would
be better (and more efficient) to get the entire result set.  I would make
a comment on the bottom of that documentation page.  IBM has been doing
good at collaborating with the community on developerWorks (which, in my
opinion, makes progress happen a lot faster than doing PMRs or DCRs).

Aaron Bartell
litmis.com - Services for open source on IBM i


On Mon, Apr 4, 2016 at 9:30 AM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

> If I'm reading the docs correctly:
>
> 1.3.15. execute
>
> *Description:*
>
> Runs a statement that was successfully prepared using *prepare*() once or
> multiple times. The statement is processed with the current values of any
> application variables that were bound to parameter markers by
> *bindParam*().
>
> *Syntax 1:*
>
> execute()
>
> *Syntax 2:*
>
> execute(function *Callback*(*OutParamList*))
>
> *Parameters **Callback*(*OutParamList*):
>
> *Callback *is a callback function to process the output parameters of the
> parameter markers. *OutParamList *is a list of the output parameters. It is
> in the java script array format.
>
> *Comments:*
>
> * If the statement also return a result set, user can issue the fetch()
> function to retrieve the data row by row.
>
>
> I believe This is saying that when using execute on a prepared statement vs
> exec on an SQL statement the rows NEEDS be processed one at a time.
>
> bummer.. returning the entire result set made things so easy to throw into
> a jade template.  :)  Now I'm going to need to change how that's done.  I
> was wondering what was better practice, looping your result set records in
> the node.js or letting your template handle it...