Single or cursor - which is better?

Sheldon Rich

Single or cursor - which is better?
We are undergoing an overall DB2 performance review which has led to
some interesting questions. What is most efficient way to "select" a single
row from within an application program. Is it better to create a cursor and
Open, Fetch, and Close OR is it better to do a singleton select?

The singleton select has fewer exec-sqls calls, but it must check for a second
row to decide if an sqlcode of -811 is needed.

So - which choice is more efficient. If you have a clue help us decide.

Thank you all,

Sheldon Rich
Bank Tfahot
[login to unmask email]

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Shery hepp

Re: Single or cursor - which is better?
(in response to Robert Catterall)
In my humble opinion a single select for 1 row only is more efficient than open, fetch close cursor because it's one instruction instead of 3 for cursor processing.

Regards, Shery

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Sheldon Rich
Sent: Tuesday, January 12, 2010 9:00 AM
To: [login to unmask email]
Subject: [DB2-L] Single or cursor - which is better?

We are undergoing an overall DB2 performance review which has led to
some interesting questions. What is most efficient way to "select" a single
row from within an application program. Is it better to create a cursor and
Open, Fetch, and Close OR is it better to do a singleton select?

The singleton select has fewer exec-sqls calls, but it must check for a second
row to decide if an sqlcode of -811 is needed.

So - which choice is more efficient. If you have a clue help us decide.

Thank you all,

Sheldon Rich
Bank Tfahot
[login to unmask email]

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Robert Catterall

Re: Single or cursor - which is better?
(in response to Sheldon Rich)
Are you looking for a "one size fits all" solution (i.e., a SELECT
construction that you could use in all cases)? Personally, I'd prefer not to
go that route. I'd rather maximize efficiency by using the technique that
best suits a given situation. If I know that a SELECT statement cannot
generate a multi-row result set (as when I reference a primary key or some
other unique key in an equal-type predicate), I'll go with a singleton
SELECT (that is, a SELECT INTO) because that minimizes calls to DB2;
otherwise, I'll go the DECLARE/OPEN/FETCH/CLOSE route.

My concerns with a one-size-fits all approach (maybe try SELECT INTO first,
check for the -811 indicating a multi-row result set, and then go with the
same SELECT in a DECLARE/OPEN/FETCH/CLOSE construct), are 1) it would not be
optimal from a CPU efficiency perspective, especially if you have a lot of
multi-row-qualifying SELECTs, and 2) it would make SQL programming more
complicated than it would otherwise be. [Consider, for example, a SELECT in
a stored procedure. Should the caller of the stored procedure expect to get
returned values in output parameters (single-row result set), or by fetching
from a cursor declared and opened in the stored procedure (multi-row result
set)?]

So, again, I don't think that I'd be comfortable with a single approach. I'd
use SELECT INTO and DECLARE/OPEN/FETCH/CLOSE as appropriate. Does that mean
that a developer needs to determine whether or not a result set would be
always-one-row or maybe-multiple-rows before writing his or her code? Yes,
but I don't see that as being too much to ask.

Robert


On Tue, Jan 12, 2010 at 11:00 AM, Sheldon Rich <[login to unmask email]> wrote:

> We are undergoing an overall DB2 performance review which has led to
> some interesting questions. What is most efficient way to "select" a
> single
> row from within an application program. Is it better to create a cursor
> and
> Open, Fetch, and Close OR is it better to do a singleton select?
>
> The singleton select has fewer exec-sqls calls, but it must check for a
> second
> row to decide if an sqlcode of -811 is needed.
>
> So - which choice is more efficient. If you have a clue help us decide.
>
> Thank you all,
>
> Sheldon Rich
> Bank Tfahot
> [login to unmask email]
>
> _____________________________________________________________________
>
> * IDUG North America * Tampa, Florida, * May 10-14 2010 *
> http://IDUG.ORG/NA *
> _____________________________________________________________________
>
> http://www.idug.org/db2-videos.html has hundreds of video presentations!
> Did you miss out on attending an IDUG conference?
> Many of the presentations were recorded and are available on our website!
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
> the home of IDUG's DB2-L
>



--
Robert Catterall
Catterall Consulting
www.catterallconsulting.com

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Stan Hoey

Re: Single or cursor - which is better?
(in response to Shery hepp)
I agree that there is no "one size fits all", but the CPU costs of
different SQL calls differ, sometimes dramatically. OPEN and CLOSE have
a very short pathlength, and there combined cost is much less than a
FETCH or SELECT.

I would only ever use a singleton SELECT if I knew for certain that only
one row would be returned.

I've always found this aging RedBook very useful for comparing the CPU
costs of SQL statements.

http://www.redbooks.ibm.com/abstracts/sg242244.html

Stan Hoey


-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Hepp Shery C
Sent: Tuesday, January 12, 2010 5:53 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Single or cursor - which is better?

In my humble opinion a single select for 1 row only is more efficient
than open, fetch close cursor because it's one instruction instead of 3
for cursor processing.

Regards, Shery

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Sheldon Rich
Sent: Tuesday, January 12, 2010 9:00 AM
To: [login to unmask email]
Subject: [DB2-L] Single or cursor - which is better?

We are undergoing an overall DB2 performance review which has led to
some interesting questions. What is most efficient way to "select" a
single row from within an application program. Is it better to create a
cursor and Open, Fetch, and Close OR is it better to do a singleton
select?

The singleton select has fewer exec-sqls calls, but it must check for a
second row to decide if an sqlcode of -811 is needed.

So - which choice is more efficient. If you have a clue help us decide.

Thank you all,

Sheldon Rich
Bank Tfahot
[login to unmask email]

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our
website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's DB2-L

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Roger Hecq

Re: Single or cursor - which is better?
(in response to Stan Hoey)
On the whole, I would have to go with the singleton select, because it
only involves one transit to DB2. From an overall performance
perspective, however, the difference betweent he two is probably
insignificant when compared to the importance assuring an optimal access
path, only returning the desired columns, etc. Obviously, the program
would have to accommodate the -811 SQL code, if that was a valid
possibility.

Roger Hecq
MF IB USA DB Support
203-719-0492 / 19-337-0492

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Sheldon Rich
Sent: Tuesday, January 12, 2010 11:00 AM
To: [login to unmask email]
Subject: [DB2-L] Single or cursor - which is better?

We are undergoing an overall DB2 performance review which has led to
some interesting questions. What is most efficient way to "select" a
single row from within an application program. Is it better to create a
cursor and Open, Fetch, and Close OR is it better to do a singleton
select?

The singleton select has fewer exec-sqls calls, but it must check for a
second row to decide if an sqlcode of -811 is needed.

So - which choice is more efficient. If you have a clue help us decide.

Thank you all,

Sheldon Rich
Bank Tfahot
[login to unmask email]

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our
website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's DB2-L
Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.


UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

John Miller

Re: Single or cursor - which is better?
(in response to Roger Hecq)
Sheldon,

Keep in mind that the cost in an OPEN/FETCH/CLOSE scenario may not
always occur on the FETCH. Depending on the access path the cost may
occur on the OPEN. This means that while your statement that a
singleton select must check for a second row is true, it's also true
that an open/fetch/close scenario may retrieve ALL rows before a FETCH
is even issued. This is especially true if you're doing an order by
that can't avoid a sort. In this scenario a singleton select is better
because it will stop executing after the second row is found.

The wording of your question indicates that you are not doing a second
fetch to check for +100. This is dangerous practice to say the least.
As a programmer if I'm only expecting 1 row to come back then I would
very much prefer to know if multiple rows qualify. Otherwise who knows
which of the qualifying rows is coming back (that's way too scary for
me). If you are doing a second fetch to check for +100 then that's no
different then a singleton select checking for -811.

If you are simply checking if a row qualifies (i.e. an existence check)
then I would recommend coding something like the following and checking
for +100:

SELECT 'X' INTO :HV
FROM TABLE1
WHERE ...
FETCH FIRST 1 ROW ONLY

If you'd like to check if more then 1 row exists then code the following
and check for -811:

SELECT 'X' INTO :HV
FROM TABLE1
WHERE ...

So I guess my answer to your question is always code a singleton select
if you only want 1 row.

Thanks,
John Miller

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Roger Hecq
Sent: Tuesday, January 12, 2010 12:32 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Single or cursor - which is better?

On the whole, I would have to go with the singleton select, because it
only involves one transit to DB2. From an overall performance
perspective, however, the difference betweent he two is probably
insignificant when compared to the importance assuring an optimal access
path, only returning the desired columns, etc. Obviously, the program
would have to accommodate the -811 SQL code, if that was a valid
possibility.

Roger Hecq
MF IB USA DB Support
203-719-0492 / 19-337-0492

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Sheldon Rich
Sent: Tuesday, January 12, 2010 11:00 AM
To: [login to unmask email]
Subject: [DB2-L] Single or cursor - which is better?

We are undergoing an overall DB2 performance review which has led to
some interesting questions. What is most efficient way to "select" a
single row from within an application program. Is it better to create a
cursor and Open, Fetch, and Close OR is it better to do a singleton
select?

The singleton select has fewer exec-sqls calls, but it must check for a
second row to decide if an sqlcode of -811 is needed.

So - which choice is more efficient. If you have a clue help us decide.

Thank you all,

Sheldon Rich
Bank Tfahot
[login to unmask email]

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our
website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's DB2-L
Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.

If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.


UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our
website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's DB2-L


The information transmitted is intended only for the addressee and may contain confidential, proprietary and/or privileged material. Any unauthorized review, distribution or other use of or the taking of any action in reliance upon this information is prohibited. If you receive this in error, please contact the sender and delete or destroy this message and any copies.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Martin Hubel

Re: Single or cursor - which is better?
(in response to John Miller)
I agree with Roger; a singleton Select is best, but you need to make sure you only get zero or one rows returned.

It brings back memories of IEF, now Coolgen, that used to blindly issue a singleton select for every query. If it received a -811, it would then use a cursor. Ugh.

--Martin

>> On the whole, I would have to go with the singleton select, because it
>> only involves one transit to DB2. From an overall performance
>> perspective, however, the difference betweent he two is probably
>> insignificant when compared to the importance assuring an optimal access
>> path, only returning the desired columns, etc. Obviously, the program
>> would have to accommodate the -811 SQL code, if that was a valid
>> possibility.

>> Roger Hecq
>> MF IB USA DB Support
>> 203-719-0492 / 19-337-0492

>> -----Original Message-----
>> From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Sheldon Rich
>> Sent: Tuesday, January 12, 2010 11:00 AM
>> To: [login to unmask email]
>> Subject: [DB2-L] Single or cursor - which is better?

>> We are undergoing an overall DB2 performance review which has led to
>> some interesting questions. What is most efficient way to "select" a
>> single row from within an application program. Is it better to create a
>> cursor and Open, Fetch, and Close OR is it better to do a singleton
>> select?

>> The singleton select has fewer exec-sqls calls, but it must check for a
>> second row to decide if an sqlcode of -811 is needed.

>> So - which choice is more efficient. If you have a clue help us decide.

>> Thank you all,

>> Sheldon Rich
>> Bank Tfahot
>> [login to unmask email]

>> _____________________________________________________________________

>> * IDUG North America * Tampa, Florida, * May 10-14 2010 *
>> http://IDUG.ORG/NA *
>> _____________________________________________________________________

>> http://www.idug.org/db2-videos.html has hundreds of video presentations!
>> Did you miss out on attending an IDUG conference?
>> Many of the presentations were recorded and are available on our
>> website!
>> _____________________________________________________________________

>> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
>> is the home of IDUG's DB2-L
>> Visit our website at http://www.ubs.com

>> This message contains confidential information and is intended only
>> for the individual named. If you are not the named addressee you
>> should not disseminate, distribute or copy this e-mail. Please
>> notify the sender immediately by e-mail if you have received this
>> e-mail by mistake and delete this e-mail from your system.
>>
>> E-mails are not encrypted and cannot be guaranteed to be secure or
>> error-free as information could be intercepted, corrupted, lost,
>> destroyed, arrive late or incomplete, or contain viruses. The sender
>> therefore does not accept liability for any errors or omissions in the
>> contents of this message which arise as a result of e-mail transmission.
>> If verification is required please request a hard-copy version. This
>> message is provided for informational purposes and should not be
>> construed as a solicitation or offer to buy or sell any securities
>> or related financial instruments.

>>
>> UBS reserves the right to retain all messages. Messages are protected
>> and accessed only in legally justified cases.

>> _____________________________________________________________________

>> * IDUG North America * Tampa, Florida, * May 10-14 2010 *
>> http://IDUG.ORG/NA *
>> _____________________________________________________________________

>> http://www.idug.org/db2-videos.html has hundreds of video presentations!
>> Did you miss out on attending an IDUG conference?
>> Many of the presentations were recorded and are available on our website!
>> _____________________________________________________________________

>> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
>> the home of IDUG's DB2-L






====================
Martin Hubel
MHC Inc.
[login to unmask email]
+1 905-764-7498
+1 416-670-7498 Mobile
Skype: db2hubel
Yahoo IM: db2hubel

Charter Member - IBM Gold Consultant Program
IBM Information Champion

Fight the Right Fires - Let us show you how
====================


The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here.

Leon Katsnelson

Re: Single or cursor - which is better?
(in response to Martin Hubel)

Bonnie Baker touched on this subject in her article in the latest IBM Data
Management magazine
http://www.ibm.com/developerworks/data/library/dmmag/DMMag_2009_Issue3/ProgrammersOnly/index.html.

I think most people will agree that singleton select is preferable because
it is faster the question is by how much and where. If your application
code is not running on the z/OS i.e. you are using DB2 Connect to do SQL
from Windows, Unux, Linux or Apple Mac then you may not even have a choice
as most common SQL APIs (CLI, ODBC, JDBC, .NET etc.) on these platforms
don't even have a concept of a singleton select and all operations are
cursor-based. This is why in DB2 Connect we spent a lot of effort to
optimise cursor operations and to make the impact of opening and closing a
cursor as small as possible. For example, if the total amount of data that
is returned fits in to a buffer (32K) then DB2 Connect will do the entire
operation in a single round trip to the mainframe. DB2 Connect will open
the cursor, fetch out all of the data and close the cursor all in one go.
Sure, there is still a cost on the DB2 side for actually doing cursor open
+close but that is minor compared to having several network flows there and
back.

So, if you can use singleton selects, go for it but if you can't, don't
sweat it and look for other places to make things go faster and use fewer
resources.

Leon Katsnelson
Program Director, IBM Data Servers
FreeDB2




From: Roger Hecq <[login to unmask email]>
To: [login to unmask email]
Date: 01/12/2010 02:36 PM.
Subject: Re: [DB2-L] Single or cursor - which is better?
Sent by: IDUG DB2-L <[login to unmask email]>



On the whole, I would have to go with the singleton select, because it
only involves one transit to DB2. From an overall performance
perspective, however, the difference betweent he two is probably
insignificant when compared to the importance assuring an optimal access
path, only returning the desired columns, etc. Obviously, the program
would have to accommodate the -811 SQL code, if that was a valid
possibility.

Roger Hecq
MF IB USA DB Support
203-719-0492 / 19-337-0492

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Sheldon Rich
Sent: Tuesday, January 12, 2010 11:00 AM
To: [login to unmask email]
Subject: [DB2-L] Single or cursor - which is better?

We are undergoing an overall DB2 performance review which has led to
some interesting questions. What is most efficient way to "select" a
single row from within an application program. Is it better to create a
cursor and Open, Fetch, and Close OR is it better to do a singleton
select?

The singleton select has fewer exec-sqls calls, but it must check for a
second row to decide if an sqlcode of -811 is needed.

So - which choice is more efficient. If you have a clue help us decide.

Thank you all,

Sheldon Rich
Bank Tfahot
[login to unmask email]

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our
website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's DB2-L
Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.


UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's DB2-L

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Peter Suhner

Re: Single or cursor - which is better?
(in response to Leon Katsnelson)
Hi Martin,
that tool has become CA Gen now (after having been "AllFusion Gen" for a
while). Did it really in the old days? Uhg!

My Gen experience is also a bit outdated meanwhile, but - at least with more
recent versions - these "singletons plus -811 checks" are done selectively,
influenced by physical data model and pseudo code options.

Which is fine then. I think we all agree that this is a nice way to avoid
unnecessary cursor handling overhead if used selectively. Many generators
out there caring even less about performance...

Peter


______________________
Peter Suhner
certified 'snow-in-the-lowlands-detester'
[login to unmask email]

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L