varying IN LIST

duam lee

varying IN LIST

Hi Listers,

I am not able to arrive at any solution for an IN LIST for SQLs having IN LIST in predicates. The INLIST can have a list of 100 for one execution or 200 in next execution. So what I am currently handling is with temp tables. What I do is insert the variabls into temp table and in original sql predicates I am doing an select from temp table. But it has been seen that it is degrading perfromances.

What I hear is if I can pass this VARYING LIST of IN LIST values in host variable or kind of ARRAY then it may be faster than the temp table funda. But I am not having any code how to code host variable array so that one can pass values to it and utilise the same in Main select. Is it possible? if any one having code please forward the same to me or reply. Please ............

With Thanks
Duam.




_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

Roy Boxwell

Re: varying IN LIST
(in response to duam lee)
I would use dynamic SQL and built the IN L;IST on hte fly...anything else
is a huge waste of effort!

Roy Boxwell
SOFTWARE ENGINEERING GMBH
-Product Development-
Robert-Stolz-Straße 5
40470 Düsseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]
http://www.seg.de

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert



duam lee <[login to unmask email]>
Gesendet von: IDUG DB2-L <[login to unmask email]>
27.01.2011 06:02
Bitte antworten an
IDUG DB2-L <[login to unmask email]>


An
[login to unmask email]
Kopie

Thema
[DB2-L] varying IN LIST






Hi Listers,

I am not able to arrive at any solution for an IN LIST for SQLs having IN
LIST in predicates. The INLIST can have a list of 100 for one execution
or 200 in next execution. So what I am currently handling is with temp
tables. What I do is insert the variabls into temp table and in original
sql predicates I am doing an select from temp table. But it has been seen
that it is degrading perfromances.

What I hear is if I can pass this VARYING LIST of IN LIST values in host
variable or kind of ARRAY then it may be faster than the temp table
funda. But I am not having any code how to code host variable array so
that one can pass values to it and utilise the same in Main select. Is
it possible? if any one having code please forward the same to me or
reply. Please ............

With Thanks
Duam.






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

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

Phil Grainger

Re: varying IN LIST
(in response to Roy Boxwell)
Or if it has to be static SQL, I'm trying to remember if DB2 is smart enough to "prune out" duplicate IN LIST values

In other words, does DB2 turn

IN (1,1,1,1,1,1,1,1,1,1,1,2,3,4) into IN (1,2,3,4)?
Phil Grainger
Cogito Ltd.
[login to unmask email]
+44 (0) 1298 872 148
+44 (0) 7505 266 768
www.cogito.co.uk <blocked:: http://www.cogito.co.uk >

Attend IDUG 2011 - the premiere events for DB2 professionals.
IDUG North America < http://www.idug.org/na > , 2-6 May, Anaheim California
IDUG EMEA < http://www.idug.org/emea > , 14-18 November, Prague Czech Republic


From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Roy Boxwell
Sent: 27 January 2011 06:17
To: [login to unmask email]
Subject: Re: [DB2-L] varying IN LIST


I would use dynamic SQL and built the IN L;IST on hte fly...anything else is a huge waste of effort!

Roy Boxwell
SOFTWARE ENGINEERING GMBH
-Product Development-
Robert-Stolz-Straße 5
40470 Düsseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]
http://www.seg.de

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert

duam lee <[login to unmask email]>
Gesendet von: IDUG DB2-L <[login to unmask email]>

27.01.2011 06:02
Bitte antworten an
IDUG DB2-L <[login to unmask email]>


An

[login to unmask email]

Kopie

Thema

[DB2-L] varying IN LIST







Hi Listers,

I am not able to arrive at any solution for an IN LIST for SQLs having IN LIST in predicates. The INLIST can have a list of 100 for one execution or 200 in next execution. So what I am currently handling is with temp tables. What I do is insert the variabls into temp table and in original sql predicates I am doing an select from temp table. But it has been seen that it is degrading perfromances.

What I hear is if I can pass this VARYING LIST of IN LIST values in host variable or kind of ARRAY then it may be faster than the temp table funda. But I am not having any code how to code host variable array so that one can pass values to it and utilise the same in Main select. Is it possible? if any one having code please forward the same to me or reply. Please ............

With Thanks
Duam.



________________________________

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >



________________________________

[ http://www.idug.org/images/banners/idug_2011.gif ] < http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

Roy Boxwell

Re: varying IN LIST
(in response to Phil Grainger)
good question - if I read the mail right he'll need 100's of duplicates
and then the optimizer might go >pop< ... Guess it is a simple case of try
it and EXPLAIN the access path.

Roy Boxwell
SOFTWARE ENGINEERING GMBH
-Product Development-
Robert-Stolz-Straße 5
40470 Düsseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]
http://www.seg.de

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert



Phil Grainger <[login to unmask email]>
Gesendet von: IDUG DB2-L <[login to unmask email]>
27.01.2011 10:53
Bitte antworten an
IDUG DB2-L <[login to unmask email]>


An
[login to unmask email]
Kopie

Thema
Re: [DB2-L] varying IN LIST






Or if it has to be static SQL, I’m trying to remember if DB2 is smart
enough to “prune out” duplicate IN LIST values

In other words, does DB2 turn

IN (1,1,1,1,1,1,1,1,1,1,1,2,3,4) into IN (1,2,3,4)?
Phil Grainger
Cogito Ltd.
[login to unmask email]
+44 (0) 1298 872 148
+44 (0) 7505 266 768
www.cogito.co.uk

Attend IDUG 2011 - the premiere events for DB2 professionals.
IDUG North America, 2-6 May, Anaheim California
IDUG EMEA, 14-18 November, Prague Czech Republic


From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Roy Boxwell
Sent: 27 January 2011 06:17
To: [login to unmask email]
Subject: Re: [DB2-L] varying IN LIST


I would use dynamic SQL and built the IN L;IST on hte fly...anything else
is a huge waste of effort!

Roy Boxwell
SOFTWARE ENGINEERING GMBH
-Product Development-
Robert-Stolz-Straße 5
40470 Düsseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]
http://www.seg.de

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert


duam lee <[login to unmask email]>
Gesendet von: IDUG DB2-L <[login to unmask email]>
27.01.2011 06:02


Bitte antworten an
IDUG DB2-L <[login to unmask email]>



An
[login to unmask email]
Kopie

Thema
[DB2-L] varying IN LIST









Hi Listers,

I am not able to arrive at any solution for an IN LIST for SQLs having IN
LIST in predicates. The INLIST can have a list of 100 for one execution
or 200 in next execution. So what I am currently handling is with temp
tables. What I do is insert the variabls into temp table and in original
sql predicates I am doing an select from temp table. But it has been seen
that it is degrading perfromances.

What I hear is if I can pass this VARYING LIST of IN LIST values in host
variable or kind of ARRAY then it may be faster than the temp table
funda. But I am not having any code how to code host variable array so
that one can pass values to it and utilise the same in Main select. Is
it possible? if any one having code please forward the same to me or
reply. Please ............

With Thanks
Duam.




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



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



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


_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

teldb2kals

Re: varying IN LIST
(in response to Roy Boxwell)
I am sure the IN-LIST duplicates are first filtered out depending on index usage. Just reconfirmed on this IBM support doc :

http://www-01.ibm.com/support/docview.wss?uid=swg21046251

"How are duplicates in an IN-list handled, and, are duplicate entries a performance problem?"

If an IN-list is used in a matching index access, DB2® sorts the values in the IN-list and gets rid of duplicates. If the IN-list is not a matching index access, duplicates can be re-evaluated multiple times.

Regards,
Kals

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

duam lee

Re: varying IN LIST
(in response to teldb2kals)

Thanks again.

But I dont have any duplicates supplied in the IN LIST and also the columns on which this IN LIST is not part of index. There are other filters in the sql in sql mpredicates where the filtering is good. But after that the in list when gets evaluated with against temp table is behaving worse.
So you suggest there is no possibility of controlling this by cobol code or cobol array.

With Thanks
Duam.




> Date: Thu, 27 Jan 2011 05:16:38 -0500
> From: [login to unmask email]
> Subject: Re: [DB2-L] varying IN LIST
> To: [login to unmask email]
>
> I am sure the IN-LIST duplicates are first filtered out depending on index usage. Just reconfirmed on this IBM support doc :
>
> http://www-01.ibm.com/support/docview.wss?uid=swg21046251
>
> "How are duplicates in an IN-list handled, and, are duplicate entries a performance problem?"
>
> If an IN-list is used in a matching index access, DB2¢ç sorts the values in the IN-list and gets rid of duplicates. If the IN-list is not a matching index access, duplicates can be re-evaluated multiple times.
>
> Regards,
> Kals
>
> _____________________________________________________________________
> * IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
> * If you are going to attend only one conference this year, this is it! *
> ** The best DB2 technical sessions in the world
> ** Independent, not-for-profit, User Run - the IDUG difference!
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv


_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

Joe Geller

Re: varying IN LIST
(in response to duam lee)
I have seen code that used a Cobol array (with a redefines on a string)
that worked the way you are suggesting. I believe the precompiler
generated code turning it into a supported format. However, I have
never seen it documented as a feature. That would mean that while
it may have worked in the past, it may no longer work as loopholes
are closed.

Joe


Thanks again.

But I dont have any duplicates supplied in the IN LIST and also the columns on which this IN LIST is not part of index. There are other filters in the sql in sql mpredicates where the filtering is good. But after that the in list when gets evaluated with against temp table is behaving worse.
So you suggest there is no possibility of controlling this by cobol code or cobol array.

With Thanks
Duam.




> Date: Thu, 27 Jan 2011 05:16:38 -0500
> From: [login to unmask email]
> Subject: Re: [DB2-L] varying IN LIST
> To: [login to unmask email]
>
> I am sure the IN-LIST duplicates are first filtered out depending on index usage. Just reconfirmed on this IBM support doc :
>
> http://www-01.ibm.com/support/docview.wss?uid=swg21046251
>
> "How are duplicates in an IN-list handled, and, are duplicate entries a performance problem?"
>
> If an IN-list is used in a matching index access, DB2® sorts the values in the IN-list and gets rid of duplicates. If the IN-list is not a matching index access, duplicates can be re-evaluated multiple times.
>
> Regards,
> Kals
>
> _____________________________________________________________________
> * IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
> * If you are going to attend only one conference this year, this is it! *
> ** The best DB2 technical sessions in the world
> ** Independent, not-for-profit, User Run - the IDUG difference!
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv


--------------------------------------------------------------------------------



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

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

Phil Grainger

Re: varying IN LIST
(in response to Joe Geller)
Duam

No, but what I was thinking was you could ALWAYS have 100 items (or however many) in your static IN LIST - by having the ones you need padded out to 100 by duplicating the last one as many times as necessary

BUT, as was pointed out below, this is not a good idea if DB2 is going to evaluate every IN LIST entry, including all the duplicates

Looks like dynamic SQL (as suggested by Roy) is the way to go
Phil Grainger
Cogito Ltd.
[login to unmask email]
+44 (0) 1298 872 148
+44 (0) 7505 266 768
www.cogito.co.uk <blocked:: http://www.cogito.co.uk >

Attend IDUG 2011 - the premiere events for DB2 professionals.
IDUG North America < http://www.idug.org/na > , 2-6 May, Anaheim California
IDUG EMEA < http://www.idug.org/emea > , 14-18 November, Prague Czech Republic


From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of duam lee
Sent: 27 January 2011 12:21
To: [login to unmask email]
Subject: Re: [DB2-L] varying IN LIST

Thanks again.

But I dont have any duplicates supplied in the IN LIST and also the columns on which this IN LIST is not part of index. There are other filters in the sql in sql mpredicates where the filtering is good. But after that the in list when gets evaluated with against temp table is behaving worse.
So you suggest there is no possibility of controlling this by cobol code or cobol array.

With Thanks
Duam.




> Date: Thu, 27 Jan 2011 05:16:38 -0500
> From: [login to unmask email]
> Subject: Re: [DB2-L] varying IN LIST
> To: [login to unmask email]
>
> I am sure the IN-LIST duplicates are first filtered out depending on index usage. Just reconfirmed on this IBM support doc :
>
> http://www-01.ibm.com/support/docview.wss?uid=swg21046251
>
> "How are duplicates in an IN-list handled, and, are duplicate entries a performance problem?"
>
> If an IN-list is used in a matching index access, DB2(r) sorts the values in the IN-list and gets rid of duplicates. If the IN-list is not a matching index access, duplicates can be re-evaluated multiple times.
>
> Regards,
> Kals
>
> _____________________________________________________________________
> * IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
> * If you are going to attend only one conference this year, this is it! *
> ** The best DB2 technical sessions in the world
> ** Independent, not-for-profit, User Run - the IDUG difference!
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

________________________________

[ http://www.idug.org/images/banners/idug_2011.gif ] < http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

Adam Baldwin

Re: varying IN LIST
(in response to Phil Grainger)
Duam, could you index the column that the IN list is based on? Did you create an index on your temporary table?

I would have thought that you you could get decent performance without going for dynamic sql.

Cheers, Adam

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

Sam Baugh

Re: varying IN LIST
(in response to Adam Baldwin)
I believe the following is valid (for COBOL anyway). I think WS-IN-LIST has to be an 01 group level, and ‎that all fields under the group must have unique names. Using a REDEFINE for the WS-IN-LIST will let ‎you set the values using array logic. I don’t know if this will make you SQL perform any better though. ‎I have found that using a JOIN is better than and IN list when possible.‎

‎01 WS-IN-LIST.‎
‎ 05 WS-IN-001 PIC X(2).‎
‎ 05 WS-IN-002 PIC X(2).‎
‎…‎
‎ 05 WS-IN-200 PIC X(2).‎

‎01 WS-IN-ARRAY REDFINES WS-IN-LIST.‎
‎ 05 WS-IN-VAR PIC X(2) OCCURS 200 TIMES.‎


Then in the SQL:
… WHERE COL1 IN (:WS-IN-LIST)‎



A possible solution for coding as a JOIN could be as follows, would just be a lot of “sql text”.‎

‎…‎
JOIN (SELECT DISTINCT COL1‎
‎ FROM (‎
‎ SELECT :WS-001 AS COL1 FROM SYSIBM.SYSDUMMY1 UNION ALL
‎ SELECT :WS-002 AS COL1 FROM SYSIBM.SYSDUMMY1 UNION ALL
‎ …‎
‎ SELECT :WS-200 AS COL1 FROM SYSIBM.SYSDUMMY1‎
‎ ) AS X‎
‎ ) AS Y‎
‎ ON Y.COL1 = your.COL‎

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

Larry Kintisch

Re: varying IN LIST
(in response to Sam Baugh)
Hi Duam,
I've read the other comments on this thread
and two sets of facts are missing.

(1) How big is the table or join where you say "filtering is good"?

If you start with 100 million rows and filter
down to 10,000 before the IN-list predicate then
using the "Declared Global Temporary file" with
an index is a great second cursor or step:
Create the TEMP_1 [ one column to hold the IN list values };
create the index;
Do the INSERTS into the TEMP_1;
Open the cursor you have --without-- the
IN-list predicate but with a SELECT that includes the IN-list column "XX";
for each fetched row
do a singleton SELECT XX from TEMP_1 where xx = :cur-xx-col;
if SQLSTATE = '00000' USE THE FETCHED ROW;
if SQLSTATE = '02000' ignore the fetched row.

By doing this you'll only test the IN-list
against filtered rows via probes of the index, in
this example, 10,000 times, much like the INNER
TABLE of a Nested Loop Join. That means at least
2 GETPAGES to the index in the buffer pool per
probe. You also come back to the COBOL program
10,000 times for the SELECT ...INTO.

[You can avoid those 10,000 back-and-forths by
having the cursor without the IN-list load a
temporary TEMP_2 with a non-unique index on XX
and JOIN that to the TEMP_1 above with a new
cursor. That should be pretty fast. ]

But if the 100 million rows filter down to
1,000,000 rows before the IN-list predicate, even
though this will work, the TEMP_1 index will be probed 1,000,000 times.

(2) You didn't tell us the "purpose" of the
IN-list. If the purpose of the IN-list predicate
is to, say, "for these 100 account numbers that
are inactive..." it is much smarter to:
ALTER the production table to add an "INACTIVE CHAR(1) " column;
add the INACTIVE column to the index that is doing the filtering;
and do the 100 updates to make the table rows
"I" in the INACTIVE column for those account numbers;
In your cursor include a predicate " AND
INACTIVE = 'I' " instead of the IN-list.
When finished, do the 100 updates to make
the table rows " " in the INACTIVE column. [A bit
of logging, but --much-- faster and --much less-- CPU.]

Hope that helps.

Larry Kintisch, Pres. ABLE Information Services 845-353-0885

At 07:21 2011-01-27, you wrote:
>Thanks again.
>
>But I dont have any duplicates supplied in the
>IN LIST and also the columns on which this IN
>LIST is not part of index. There are other
>filters in the sql in sql mpredicates where the
>filtering is good. But after that the in list
>when gets evaluated with against temp table is behaving worse.
>So you suggest there is no possibility of
>controlling this by cobol code or cobol array.
>
>With Thanks
>Duam.
>
>
>
>
> > Date: Thu, 27 Jan 2011 05:16:38 -0500
> > From: [login to unmask email]
> > Subject: Re: [DB2-L] varying IN LIST
> > To: [login to unmask email]
> >
> > I am sure the IN-LIST duplicates are first
> filtered out depending on index usage. Just
> reconfirmed on this IBM support doc :
> >
> > http://www-01.ibm.com/support/docview.wss?uid=swg21046251
> >
> > "How are duplicates in an IN-list handled,
> and, are duplicate entries a performance problem?"
> >
> > If an IN-list is used in a matching index
> access, DB2¢ç sorts the values in the IN-list
> and gets rid of duplicates. If the IN-list is
> not a matching index access, duplicates can be re-evaluated multiple times.
> >
> > Regards,
> > Kals
> >
> > _____________________________________________________________________
> > * IDUG EMEA * Prague, Czech Republic * 14-18
> November 2011 * http://IDUG.ORG/EMEA *
> > * If you are going to attend only one conference this year, this is it! *
> > ** The best DB2 technical sessions in the world
> > ** Independent, not-for-profit, User Run - the IDUG difference!
> > _____________________________________________________________________
> >
> > If you need to change settings,
> http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv
>
>No virus found in this message.
>Checked by AVG - < http://www.avg.com > www.avg.com
>Version: 10.0.1202 / Virus Database: 1435/3404 - Release Date: 01/26/11
>
>
> < http://www.idug.org >
>Independent, not-for-profit, User Run - the IDUG difference!
>
>
>The IDUG DB2-L Listserv is only part of your
>membership in IDUG. If you are not already an
>IDUG member, < http://www.idug.org/register > please register here.

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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