By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,469 Members | 1,259 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,469 IT Pros & Developers. It's quick & easy.

MERGE from TABLE INTO VIEW - DB2 LUW V8 FP12

P: n/a
Hi All:

I need some clarification on a MERGE statement. The database is on V8
FP12 (AIX) 64bit.

The source table is tableA.
The target is a View "FACT" with UNION ALL because of the 512 Gig
restriction.

Will a MERGE into this view "FACT" from tableA work?

Ran an explain on the merge and the explain fails with:
SQL0150N The target fullselect, view, typed table, materialized query
table,
or staging table in the INSERT, DELETE, UPDATE, or MERGE statement is a
target
for which the requested operation is not permitted. SQLSTATE=42807

The view definition is:
create view FACT select * from FactA UNION ALL select * from FactB with
ROW MOVEMENT

Is merge supported in this case?

Thanks.

Vijay

Aug 9 '06 #1
Share this Question
Share on Google+
16 Replies


P: n/a
UDBDBA wrote:
Hi All:

I need some clarification on a MERGE statement. The database is on V8
FP12 (AIX) 64bit.

The source table is tableA.
The target is a View "FACT" with UNION ALL because of the 512 Gig
restriction.

Will a MERGE into this view "FACT" from tableA work?

Ran an explain on the merge and the explain fails with:
SQL0150N The target fullselect, view, typed table, materialized query
table,
or staging table in the INSERT, DELETE, UPDATE, or MERGE statement is a
target
for which the requested operation is not permitted. SQLSTATE=42807

The view definition is:
create view FACT select * from FactA UNION ALL select * from FactB with
ROW MOVEMENT

Is merge supported in this case?
I just reproduced on DB2 9, so the answer is: "apparently not". But I
can't find the limitation documented....
Of course you can work around using INSTEAD OF triggers, but that would
slow INSERTs and UPDATEs down.
Technically you could open a PMR, but the outcome will be a doc-APAR not
a code APAR. Since DB2 9 has range partitioning and large rowids there
is little incentive to customers or IBM to improve UNION ALL support for
views.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 9 '06 #2

P: n/a
Serge:

I don't believe this (Argh! Ouch!)...

Just to clarify my sleepy head..... Merge is NOT supported on UNION ALL
VIEWS.

Correct?

Can I convert the merge statements into Upsert logic?

Thanks!

Vijay
Serge Rielau wrote:
Is merge supported in this case?
I just reproduced on DB2 9, so the answer is: "apparently not". But I
can't find the limitation documented....
Of course you can work around using INSTEAD OF triggers, but that would
slow INSERTs and UPDATEs down.
Aug 9 '06 #3

P: n/a
UDBDBA wrote:
Serge:

I don't believe this (Argh! Ouch!)...

Just to clarify my sleepy head..... Merge is NOT supported on UNION ALL
VIEWS.

Correct?
No. The limitation relates to WITH ROW MOVEMENT, not UNION ALL as such.
As long as you don't allow shuffling your "view partitioning keys" you
are OK (I just tested with a view with NO ROW MOVEMENT and it worked).
WITH ROW MOVEMENT is pretty complex and so is MERGE. I'm not too
surprised that we (chances are I made the call myself and I just don't
remember ;-) decided that it's not worth the effort given range
partitioning was around the corner.
Can I convert the merge statements into Upsert logic?
Of course. Like in the olden days.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 9 '06 #4

P: n/a
Thank you!

Serge Rielau wrote:
UDBDBA wrote:
Serge:

I don't believe this (Argh! Ouch!)...

Just to clarify my sleepy head..... Merge is NOT supported on UNION ALL
VIEWS.

Correct?
No. The limitation relates to WITH ROW MOVEMENT, not UNION ALL as such.
As long as you don't allow shuffling your "view partitioning keys" you
are OK (I just tested with a view with NO ROW MOVEMENT and it worked).
WITH ROW MOVEMENT is pretty complex and so is MERGE. I'm not too
surprised that we (chances are I made the call myself and I just don't
remember ;-) decided that it's not worth the effort given range
partitioning was around the corner.
Can I convert the merge statements into Upsert logic?
Of course. Like in the olden days.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 9 '06 #5

P: n/a
And the merge works with UNION ALL views WITH NO ROW MOVEMENT.

Thanks Serge.

- Vijay
UDBDBA wrote:
Thank you!

Serge Rielau wrote:
UDBDBA wrote:
Serge:
>
I don't believe this (Argh! Ouch!)...
>
Just to clarify my sleepy head..... Merge is NOT supported on UNION ALL
VIEWS.
>
Correct?
No. The limitation relates to WITH ROW MOVEMENT, not UNION ALL as such.
As long as you don't allow shuffling your "view partitioning keys" you
are OK (I just tested with a view with NO ROW MOVEMENT and it worked).
WITH ROW MOVEMENT is pretty complex and so is MERGE. I'm not too
surprised that we (chances are I made the call myself and I just don't
remember ;-) decided that it's not worth the effort given range
partitioning was around the corner.
Can I convert the merge statements into Upsert logic?
Of course. Like in the olden days.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 9 '06 #6

P: n/a
Hi:

The merge runs very slow on a view with two tables under it. If I run
the merge on the 2 tables directly, it finishes in minutes. The merge
on view runs for ever...

Any tips on improving merge performance with views?

Thanks!

Vijay
UDBDBA wrote:
And the merge works with UNION ALL views WITH NO ROW MOVEMENT.

Thanks Serge.

- Vijay
UDBDBA wrote:
Thank you!

Serge Rielau wrote:
UDBDBA wrote:
Serge:

I don't believe this (Argh! Ouch!)...

Just to clarify my sleepy head..... Merge is NOT supported on UNION ALL
VIEWS.

Correct?
No. The limitation relates to WITH ROW MOVEMENT, not UNION ALL as such.
As long as you don't allow shuffling your "view partitioning keys" you
are OK (I just tested with a view with NO ROW MOVEMENT and it worked).
WITH ROW MOVEMENT is pretty complex and so is MERGE. I'm not too
surprised that we (chances are I made the call myself and I just don't
remember ;-) decided that it's not worth the effort given range
partitioning was around the corner.
>
Can I convert the merge statements into Upsert logic?
Of course. Like in the olden days.
>
Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
>
IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 13 '06 #7

P: n/a
UDBDBA wrote:
Hi:

The merge runs very slow on a view with two tables under it. If I run
the merge on the 2 tables directly, it finishes in minutes. The merge
on view runs for ever...

Any tips on improving merge performance with views?
I doubt the problem is the view as such. It's probably the UNION ALL.
Can you post the db2exfmt output? MERGE has pretty demanding semantics.
If the optimizer doesn't detect query rewrite opportunities thing scan
get messy.
E.g. a UNION ALL dictates that the MERGE target doesn't have a unique
attribute on your ON clause. Not sure what that may break...

Cheers
Serge

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 13 '06 #8

P: n/a
Hi Serge:

Thank you.

I had to use UNION ALL for the MERGE to run. The merge does not run
against a UNION view WITH NO ROW MOVEMENT. So, it looks like we have to
declare the view with ALL for MERGE to run...

Here is the db2exfmt output.

Vijay

Access Plan:
-----------
Total Cost: 220.593
Query Degree: 0

Rows
RETURN
( 1)
FstTup
I/O
|
1.52198e-05
UPDATE
( 2)
220.593
101
/----+----\
1.52198e-05 2.72161e+08
FETCH TABLE: STELLA
( 3) FACTRANSB
220.593
101
/----+----\
1.52198e-05 2.72161e+08
UPDATE TABLE: STELLA
( 4) FACTRANSB
220.593
101
/----+----\
1.52198e-05 3.61394e+08
FETCH TABLE: STELLA
( 5) FACTRANSA
220.593
101
/----+----\
1.52198e-05 3.61394e+08
FILTER TABLE: STELLA
( 6) FACTRANSA
220.592
101
|
0.000380494
NLJOIN
( 7)
218.6
101
/--------+--------\
0.000380494 1.28058e-30
FETCH TBSCAN
( 8) ( 10)
21.3462 197.254
2.00038 98
/----+----\ |
0.000380494 3.80494e+06 1.28058e-30
IXSCAN TABLE: STAGE TEMP
( 9) QFACTRANS_CHRG ( 11)
21.3421 197.241
2 98
| |
3.80494e+06 1.28058e-30
INDEX: STAGE FILTER
QFACTRANS_CHRG_U ( 12)
197.236
98
|
0.0185398
UNION
( 13)
159.209
98
/-------------+-------------\
2.72161e-07 0.0185395
FETCH MSJOIN
( 14) ( 16)
31.3661 127.843
33 65
/----+----\ /--------+-------\
1.40146e-05 2.72161e+08 0.0361394 0.513
IXSCAN TABLE: STELLA FETCH FILTER
( 15) FACTRANSB ( 17) ( 19)
12.8641 127.813
0.00270878
1 65 0
| /---+---\ |
2.72161e+08 1.74675 3.61394e+08 2
INDEX: SYSIBM IXSCAN TABLE: STELLA TBSCAN
SQL0608062124063 ( 18) FACTRANSA ( 20)
12.864
0.00270878
1 0
| |
3.61394e+08 2
INDEX: SYSIBM SORT
SQL0608071113407 ( 21)

0.00211486
0
|
2
TBSCAN
( 22)

3.71971e-05
0
|
2
TABFNC:
SYSIBM
GENROW

Serge Rielau wrote:
UDBDBA wrote:
Hi:

The merge runs very slow on a view with two tables under it. If I run
the merge on the 2 tables directly, it finishes in minutes. The merge
on view runs for ever...

Any tips on improving merge performance with views?
I doubt the problem is the view as such. It's probably the UNION ALL.
Can you post the db2exfmt output? MERGE has pretty demanding semantics.
If the optimizer doesn't detect query rewrite opportunities thing scan
get messy.
E.g. a UNION ALL dictates that the MERGE target doesn't have a unique
attribute on your ON clause. Not sure what that may break...

Cheers
Serge

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 14 '06 #9

P: n/a
Hi Serge:

here is the access plan for the MERGE running on the table (without the
view):

Optimizer Plan:

UPDATE
( 2)
/ \
FILTER Table:
( 3) STELLA
| FACTRANSB
NLJOIN
( 4)
/-/ \
FETCH FETCH
( 5) ( 4)
| |
IXSCAN IXSCAN
( 5) ( 4)
| |
Index: Index:
STAGE STELLA
QFACTRANS_CHRG_U2 FACTRANSB_FIX

Thanks.

Vijay

UDBDBA wrote:
Hi Serge:

Thank you.

I had to use UNION ALL for the MERGE to run. The merge does not run
against a UNION view WITH NO ROW MOVEMENT. So, it looks like we have to
declare the view with ALL for MERGE to run...

Here is the db2exfmt output.

Vijay

Access Plan:
-----------
Total Cost: 220.593
Query Degree: 0

Rows
RETURN
( 1)
FstTup
I/O
|
1.52198e-05
UPDATE
( 2)
220.593
101
/----+----\
1.52198e-05 2.72161e+08
FETCH TABLE: STELLA
( 3) FACTRANSB
220.593
101
/----+----\
1.52198e-05 2.72161e+08
UPDATE TABLE: STELLA
( 4) FACTRANSB
220.593
101
/----+----\
1.52198e-05 3.61394e+08
FETCH TABLE: STELLA
( 5) FACTRANSA
220.593
101
/----+----\
1.52198e-05 3.61394e+08
FILTER TABLE: STELLA
( 6) FACTRANSA
220.592
101
|
0.000380494
NLJOIN
( 7)
218.6
101
/--------+--------\
0.000380494 1.28058e-30
FETCH TBSCAN
( 8) ( 10)
21.3462 197.254
2.00038 98
/----+----\ |
0.000380494 3.80494e+06 1.28058e-30
IXSCAN TABLE: STAGE TEMP
( 9) QFACTRANS_CHRG ( 11)
21.3421 197.241
2 98
| |
3.80494e+06 1.28058e-30
INDEX: STAGE FILTER
QFACTRANS_CHRG_U ( 12)
197.236
98
|
0.0185398
UNION
( 13)
159.209
98
/-------------+-------------\
2.72161e-07 0.0185395
FETCH MSJOIN
( 14) ( 16)
31.3661 127.843
33 65
/----+----\ /--------+-------\
1.40146e-05 2.72161e+08 0.0361394 0.513
IXSCAN TABLE: STELLA FETCH FILTER
( 15) FACTRANSB ( 17) ( 19)
12.8641 127.813
0.00270878
1 65 0
| /---+---\ |
2.72161e+08 1.74675 3.61394e+08 2
INDEX: SYSIBM IXSCAN TABLE: STELLA TBSCAN
SQL0608062124063 ( 18) FACTRANSA ( 20)
12.864
0.00270878
1 0
| |
3.61394e+08 2
INDEX: SYSIBM SORT
SQL0608071113407 ( 21)

0.00211486
0
|
2
TBSCAN
( 22)

3.71971e-05
0
|
2
TABFNC:
SYSIBM
GENROW

Serge Rielau wrote:
UDBDBA wrote:
Hi:
>
The merge runs very slow on a view with two tables under it. If I run
the merge on the 2 tables directly, it finishes in minutes. The merge
on view runs for ever...
>
Any tips on improving merge performance with views?
I doubt the problem is the view as such. It's probably the UNION ALL.
Can you post the db2exfmt output? MERGE has pretty demanding semantics.
If the optimizer doesn't detect query rewrite opportunities thing scan
get messy.
E.g. a UNION ALL dictates that the MERGE target doesn't have a unique
attribute on your ON clause. Not sure what that may break...

Cheers
Serge

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 15 '06 #10

P: n/a
UNION is not updatable, so that you require UNION ALL makes sense.
The merge as such seems to be optimized as good as it gets, but your
cardinality estimates are in la-la-land. 10 to the power of -30 is just
nuts.
Do you have distribution stats?

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 15 '06 #11

P: n/a
Hi Serge:

Thank you!

Yes. The table has distribution statistics. Indexes don't have DETAILED
statistics, just basic index statistics. Because of SELECTIVITY reason
the cardinality is in la la land...

Below is the merge statement without selectivity (db2exfmt plan given
below for the below statement)

merge into STELLA.FACTRANS as FT
using (select
<column list>
from STAGE.QFACTRANS_CHRG
where DWCONTRACTID = 2246
and TRANSTYPE = 'C'
and BATCHNO = '200607' ) as SC
on FT.KEYFACCHARGE = SC.KEYFACCHARGE
and FT.DWCONTRACTID = SC.DWCONTRACTID
and FT.KEYFACCHARGE = SC.KEYFACTRANS
and FT.BATCHNO <= '200607'
and FT.TRANSTYPE in ('A','P')
and FT.DWCONTRACTID = 2246
when matched then update
set < column list >

Here is the plan without selectivity, no better. When run it it makes
no difference.
The duplicate row elimiation branch moved up after joining the view
with the table....

Access Plan:
-----------
Total Cost: 5051.16
Query Degree: 0

Rows
RETURN
( 1)
FstTup
I/O
|
0.04
UPDATE
( 2)
5051.16
2598.16
/---+---\
0.04 2.72161e+08
FETCH TABLE: STELLA
( 3) FACTRANSB
5050.64
2598.12
/---+---\
0.04 2.72161e+08
UPDATE TABLE: STELLA
( 4) FACTRANSB
5050.13
2598.08
/---+---\
0.04 3.61394e+08
FETCH TABLE: STELLA
( 5) FACTRANSA
5049.62
2598.04
/---+--\
0.04 3.61394e+08
TBSCAN TABLE: STELLA
( 6) FACTRANSA
5049.1
2598
|
0.04
TEMP
( 7)
5049.09
2598
|
0.04
FILTER
( 8)
5049.08
2598
|
1
NLJOIN
( 9)
5049.08
2598
/--------+-------\
1 1.4642e-11
FETCH FILTER
( 10) ( 12)
31.9468 5017.13
3 2595
/---+---\ |
1 3.80494e+06 158986
IXSCAN TABLE: STAGE UNION
( 11) QFACTRANS_CHRG ( 13)
21.3009 31.3699
2 2595
| /------------+------------\
3.80494e+06 62371 96614.9
INDEX: STAGE FETCH NLJOIN
QFACTRANS_CHRG_I ( 14) ( 16)
31.3699 31.3696
1057 1538
/---+---\ /------+------\
32.1172 2.72161e+08 2 48307.5
IXSCAN TABLE: STELLA TBSCAN FETCH
( 15) FACTRANSB ( 17) ( 18)
12.8646 3.71971e-05 31.3694
1 0 769
| | /---+---\
2.72161e+08 2 23.3488
3.61394e+08
INDEX: SYSIBM TABFNC: SYSIBM IXSCAN TABLE:
STELLA
SQL0608062124063 GENROW ( 19)
FACTRANSA
12.864
1
|
3.61394e+08
INDEX: SYSIBM
SQL0608071113407
Thanks!

Vijay

Serge Rielau wrote:
UNION is not updatable, so that you require UNION ALL makes sense.
The merge as such seems to be optimized as good as it gets, but your
cardinality estimates are in la-la-land. 10 to the power of -30 is just
nuts.
Do you have distribution stats?

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 15 '06 #12

P: n/a
Which columns are your keys on each table?
How many rows are really updated (SQLCA.ERRD[3])?

Cheers
Serge

PS: Any chance to get you to DB2 9 with range partitioning?
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 15 '06 #13

P: n/a
Hi Serge:

All columns that start with KEY are all Surrogate key columns and are
unique.
The key columns are:
Source table: keyfactrans, keyfaccharge, dwcontractid --unique index
Target FACT table: keyfactrans, keyfaccharge, dwcontractid --regular
index (MDC table)

All rows that qualify in the merge are updated. It's a 100% update.
For now, I have copied the merge statement and run them against both
the fact tables and it works!

We are going Viper for sure, in the next month or two with
RANGE/HASH/MDC for FACT table.

What do you suggest and where do you think the problem is?

Thanks for your help!

Vijay

Serge Rielau wrote:
Which columns are your keys on each table?
How many rows are really updated (SQLCA.ERRD[3])?

Cheers
Serge

PS: Any chance to get you to DB2 9 with range partitioning?
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 15 '06 #14

P: n/a
I don't have a FP12 handy, but here is what I got on DB2 9
(I'm not aware of any MERGE fixes in DB2 V8 past FP9).
My example is simplified but shows that UNION ALL should cause any
grief. Can you send me your DDL for the three tables and the view?
CREATE TABLE T1(pk INT NOT NULL PRIMARY KEY, c1 int);
CREATE TABLE T2(pk INT NOT NULL PRIMARY KEY, c1 int);
CREATE VIEW V AS SELECT * FROM T1 UNION ALL SELECT * FROM T2;

CREATE TABLE S(pk INT NOT NULL PRIMARY KEY, c1 int);

MERGE INTO V USING S ON V.pk = S.pk
WHEN MATCHED THEN UPDATE SET c1 = v.c1;

Access Plan:
-----------
Total Cost: 122.149
Query Degree: 1

Rows
RETURN
( 1)
Cost
I/O
|
6.04
UPDATE
( 2)
122.149
16.08
/---+---\
6.04 151
FETCH TABLE: SRIELAU
( 3) T2
76.4588
10.04
/---+---\
6.04 151
UPDATE TABLE: SRIELAU
( 4) T2
68.8918
9.04
/---+---\
6.04 151
FETCH TABLE: SRIELAU
( 5) T1
23.2013
3
/---+---\
6.04 151
FILTER TABLE: SRIELAU
( 6) T1
15.6332
2
|
151
HSJOIN
( 7)
15.5802
2
/---------+--------\
302 151
UNION IXSCAN
( 8) ( 11)
15.3438 0.107397
2 0
/-----+-----\ |
151 151 151
TBSCAN TBSCAN INDEX: SYSIBM
( 9) ( 10) SQL060815115006160
7.67188 7.67188
1 1
| |
151 151
TABLE: SRIELAU TABLE: SRIELAU
T2 T1

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 15 '06 #15

P: n/a
That's a clean merge...I have a V9 sample database and perhaps could
try this one on my side too with the actual tables with no data...
Email on it's way with DDL and merge statement...

Thanks!

Vijay
Serge Rielau wrote:
I don't have a FP12 handy, but here is what I got on DB2 9
(I'm not aware of any MERGE fixes in DB2 V8 past FP9).
My example is simplified but shows that UNION ALL should cause any
grief. Can you send me your DDL for the three tables and the view?
CREATE TABLE T1(pk INT NOT NULL PRIMARY KEY, c1 int);
CREATE TABLE T2(pk INT NOT NULL PRIMARY KEY, c1 int);
CREATE VIEW V AS SELECT * FROM T1 UNION ALL SELECT * FROM T2;

CREATE TABLE S(pk INT NOT NULL PRIMARY KEY, c1 int);

MERGE INTO V USING S ON V.pk = S.pk
WHEN MATCHED THEN UPDATE SET c1 = v.c1;

Access Plan:
-----------
Total Cost: 122.149
Query Degree: 1

Rows
RETURN
( 1)
Cost
I/O
|
6.04
UPDATE
( 2)
122.149
16.08
/---+---\
6.04 151
FETCH TABLE: SRIELAU
( 3) T2
76.4588
10.04
/---+---\
6.04 151
UPDATE TABLE: SRIELAU
( 4) T2
68.8918
9.04
/---+---\
6.04 151
FETCH TABLE: SRIELAU
( 5) T1
23.2013
3
/---+---\
6.04 151
FILTER TABLE: SRIELAU
( 6) T1
15.6332
2
|
151
HSJOIN
( 7)
15.5802
2
/---------+--------\
302 151
UNION IXSCAN
( 8) ( 11)
15.3438 0.107397
2 0
/-----+-----\ |
151 151 151
TBSCAN TBSCAN INDEX: SYSIBM
( 9) ( 10) SQL060815115006160
7.67188 7.67188
1 1
| |
151 151
TABLE: SRIELAU TABLE: SRIELAU
T2 T1

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 15 '06 #16

P: n/a
Here is your problem :-)
on FT.KEYFACCHARGE = SC.KEYFACCHARGE
and FT.DWCONTRACTID = SC.DWCONTRACTID
and _FT.KEYFACCHARGE_ = SC.KEYFACTRANS -- <----

Cheers
Serge

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 15 '06 #17

This discussion thread is closed

Replies have been disabled for this discussion.