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

SP returns resultset in Control Center, but empty resultset from command line

P: n/a
Hi all,

I've put together a few SPs to produce a BOM (bill of materials)
listing, which together use a couple of global temp tables, and return
the results from a cursor. Here's the code:
-- Initialize the temp tables............
create procedure myschema.init_ebom_tables ( )
language sql
specific init_ebom_tables
-- wlm environment <env>
te: begin

declare v_lvl smallint;

-- Declare global temp table to hold results........
declare global temporary table session.ebom_temp
( zaehler integer not null
generated always as identity
( start with 1
increment by 1 ),
nlevel smallint not null,
struktur varchar(16) not null,
item varchar(47) not null,
item_desc varchar(30) not null,
pos smallint not null,
cha varchar(10) not null,
s_item varchar(47) not null,
s_desc varchar(30) not null,
quantity decimal(16, 4) not null,
units varchar(10) not null
)
with replace
on commit preserve rows;
create unique index session.ebom_tempX1 on session.ebom_temp
(zaehler);
create index session.ebom_tempX2 on session.ebom_temp (item, s_item);

-- Declare global temp table to hold multipliers........
declare global temporary table session.ebom_multipliers
( nlevel integer not null
generated always as identity
( start with 1
increment by 1 ),
multiplier decimal(20, 6) not null
)
with replace
on commit preserve rows;
create unique index session.ebom_multipliersX1 on
session.ebom_multipliers (nlevel);

-- ...and give it 16 levels (the maximum nesting depth for SPs) .....
set v_lvl = 0;
while (v_lvl < 16) do
set v_lvl = v_lvl + 1;
insert into session.ebom_multipliers
(nlevel, multiplier)
values (default, 1);
end while;

end te
@
-- Fire up the first call.......................
create procedure myschema.get_bom_struktur (in p_top_item varchar(47),
in p_bom_type varchar(1))
language sql
specific get_bom_struktur
-- wlm environment <env>
dynamic result sets 1
gbs: begin

declare v_sql varchar(100) default 'select * from session.ebom_temp
order by zaehler ';
--declare v_sql varchar(100) default 'select * from bb.ttaihz040777
fetch first 10 rows only ';
declare bom_listing cursor with return to client for stmt;

-- Make first call to recursive SP to actually generate the
BOM......
if (upper(p_bom_type) = 'E') then
call myschema.eng_bom_inner(p_top_item, 1);
else
call myschema.prod_bom_inner(p_top_item, 1);
end if;

-- Return final resultset dynamically.....
begin
prepare stmt from v_sql;
open bom_listing;
end;

-- Return final resultset directly.....
-- begin
-- declare bom_listing cursor with return to client for
-- select *
-- from session.ebom_temp
-- order by zaehler;
-- open bom_listing;
-- end;

end gbs
@

-- Recursive inner routine................
create procedure myschema.eng_bom_inner (in p_item varchar(47), in
p_level smallint)
language sql
specific eng_bom_inner
-- wlm environment <env>
dynamic result sets 1
ebi: begin

declare v_eitm varchar(47);
declare v_itmdesc varchar(30);
declare v_pono smallint;
declare v_comp varchar(47);
declare v_cmpdesc varchar(30);
declare v_nqan decimal(12, 2);
declare sqlstate char(5) default '00000';
declare v_nextlvl smallint;
declare v_dynCall varchar(100) default ' call
myschema.eng_bom_inner(?, ?) ';

-- Set up the main cursor...............
cur: begin
declare e_bom_cur cursor with hold for

select bm.t_eitm, item_desc(bm.t_eitm), bm.t_pono, bm.t_comp,
item_desc(bm.t_comp), bm.t_nqan
from bb.ttiedm110100 as bm -- Engineering BOMs....
where bm.t_eitm = p_item
and bm.t_revi = (select max(t.t_revi) from bb.ttiedm110100 as t
-- get highest revision for this P/N
where t.t_eitm = bm.t_eitm
-- (index 1 on t_eitm, t_revi, t_pono)...
fetch first 1 rows only)
order by bm.t_pono
for fetch only;
--with cr

open e_bom_cur;
fetch from e_bom_cur into v_eitm, v_itmdesc, v_pono, v_comp,
v_cmpdesc, v_nqan;

while (sqlstate = '00000') do

update session.ebom_multipliers -- These values not yet being
used....
set multiplier = v_nqan
where nlevel = p_level;

-- Save these details to the temp table............
insert into session.ebom_temp
( zaehler, nlevel, struktur, item, item_desc, pos, cha, s_item,
s_desc, quantity, units )
values (default, p_level, repeat('*', p_level), p_item, v_itmdesc,
v_pono, '', v_comp, v_cmpdesc, v_nqan, '');

-- Call this sp recursively - this has to be done using dynamic
SQL,
-- because deferred object validation is not supported on
LUW........
set v_nextlvl = p_level + 1;
prepare v_stmt from v_dynCall;
execute v_stmt using v_comp, v_nextlvl;

-- Get the next row.....
fetch from e_bom_cur into v_eitm, v_itmdesc, v_pono, v_comp,
v_cmpdesc, v_nqan;
end while;

close e_bom_cur;
end cur;

end ebi
@

OK - here's the problem: when I run this in the DB2 Control Center
("call myschema.get_bom_struktur(...)"), it all runs well, and produces
the correct resultset - for large BOMs, it takes maybe half a minute to
produce several thousand lines. Not exactly speedy, but perfectly
adequate.

When I run the same command from the command line (DB2 CLP), however,
the thing returns immediately, apparently without ever touching the
'e_bom_cur' cursor in the 'eng_bom_inner' SP. The user (me!) has full
execute rights on all these SPs. Running the same command from a test
Windows program (where I'm certainly no newbie!) also returns
immediately, again with an empty resultset.

If I change the final cursor in the "get_bom_struktur" SP so that it
returns data from some other (non-temporary) table, the resultset is
not empty, regardless of where it has been called from. It's my guess
then, that the problem has something to do with the visibility of the
global temp tables.

I'd appreciate some help on this, since I'm hoping to use similar
methods to generate other listings.

TIA,
Rob

Oct 14 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
1. Are you absolutely,positively sur eyou call teh same procedure?
Make sure you call it with it's qualified name to avoid PATH playing a role.
2. Haven't analyzed this in detail for your routine, but in general
having cursors open on tables which you modify yourself yields non
deterministic behavior due plan dependent buffering of the cursor result set
3. DB2 for LUW supports recursion natively using common table
expressions and union all. That will be a magnitudes faster. There are
examples on DeveloperWorks, in Graeme Birchall's free online book and of
course in the DB2 Information Center

Oh.. and I explain recursion at IOD coming week too :-)
Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

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

P: n/a
Hi Serge,

-- Previous reply killed by stupid computer--

Point 1) Yes, I'm calling absolutely the same procedure via
schema_name.proc_name.

Point 2) But I should get _some_ results, right?

Point 3) Yes, I've already written some routines to produce BOM
listings via "native recursion" and using common table expressions and
union all and, as you say, they run extremely quickly but don't give me
the sorting I'm after. I've played around with the routines in an
attempt to get a rowcount/rownumber included, but haven't yet figured
how to do this.

I have Graeme's book (more power to his elbow) - I've also got "DB2
SQL PL: Essential Guide for DB2 UDB on Linux, UNIX, Windows, i5/OS, and
z/OS (2nd edition)" by Janmohamed et al. - both of which have got me up
and running on DB2 in record time. Well, at least for me, anyway ;-)...
Oh.. and I explain recursion at IOD coming week too :-) - Ahhh, what a shame, I won't be there - I'm sure I 'd learn a bunch...
Cheers,
Rob

Serge Rielau wrote:
1. Are you absolutely,positively sur eyou call teh same procedure?
Make sure you call it with it's qualified name to avoid PATH playing a role.
2. Haven't analyzed this in detail for your routine, but in general
having cursors open on tables which you modify yourself yields non
deterministic behavior due plan dependent buffering of the cursor result set
3. DB2 for LUW supports recursion natively using common table
expressions and union all. That will be a magnitudes faster. There are
examples on DeveloperWorks, in Graeme Birchall's free online book and of
course in the DB2 Information Center

Oh.. and I explain recursion at IOD coming week too :-)
Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

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

P: n/a
Have you looked at this one? Different spin, but it handles numbering.
http://www.ibm.com/developerworks/db...dm-0510rielau/
Also, what happens when you debug the beast? (print into a temp or using
the SQL PL Debugger of Developer Center or Developer Workbench?

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

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

P: n/a
robertino wrote:
Hi Serge,

-- Previous reply killed by stupid computer--

Point 1) Yes, I'm calling absolutely the same procedure via
schema_name.proc_name.
Same set of parameters?
Point 3) Yes, I've already written some routines to produce BOM
listings via "native recursion" and using common table expressions and
union all and, as you say, they run extremely quickly but don't give me
the sorting I'm after.
Then you should figure out exactly which ORDER BY clause you need because
that's the _only_ way to ensure a certain ordering of rows in a result set.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Oct 16 '06 #5

P: n/a
Knut,

thanks for the input - yes, I'm using exactly the same paramaters.
>>Then you should figure out exactly which ORDER BY clause you need because
that's the _only_ way to ensure a certain ordering of rows in a result set.
Well, I'm very familiar with the ORDER BY clause (I'm coming from a SQL
Server/MySQL background) but, in this case, you're not right - it's NOT
the only way. After reading Serge's article
http://www.ibm.com/developerworks/db...dm-0510rielau/
on recursion, I see that there are (at least) two ways of achieving a
BOM or similar listing:

1) by depth (as Oracle in the article, or as my set of SPs),
2) by breadth (as DB2 with its' style of recursion using CTE's)

The simplest example of each of these will generate different sortings,
since they traverse the "tree" in different ways. What I'm trying to
do is achieve a "depth first" sorting from DB2's "breadth first"
listing. The article shows a way of doing this: for a newcomer to DB2
and CTE's, the means of achieving this result are not exactly
intuitive, but I was headed in roughly the right direction. I'll be
playing around with these ideas as I find time to do so...

Having said all that, I still am left with my original problem: my SPs,
which run exactly as intended in the DB2 Control Center (and which, by
traversing the tree "depth first", naturally give me the sorting I
require), do not run as intended on the DB2 CLP, or from an external
application. And I'd very much like to know why.

Thanks,
Rob

On Oct 16, 8:42 am, Knut Stolze <sto...@de.ibm.comwrote:
robertino wrote:
Hi Serge,
-- Previous reply killed by stupid computer--
Point 1) Yes, I'm calling absolutely the same procedure via
schema_name.proc_name.Same set of parameters?
Point 3) Yes, I've already written some routines to produce BOM
listings via "native recursion" and using common table expressions and
union all and, as you say, they run extremely quickly but don't give me
the sorting I'm after.Then you should figure out exactly which ORDER BY clause you need because
that's the _only_ way to ensure a certain ordering of rows in a result set.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Oct 16 '06 #6

P: n/a
robertino wrote:
Knut,

thanks for the input - yes, I'm using exactly the same paramaters.
>>>Then you should figure out exactly which ORDER BY clause you need because
that's the _only_ way to ensure a certain ordering of rows in a result
set.

Well, I'm very familiar with the ORDER BY clause (I'm coming from a SQL
Server/MySQL background) but, in this case, you're not right - it's NOT
the only way.
Sorry, but it is. The DBMS can return the rows in any way it likes unless
you provide an explicit ORDER BY in your query. Everything else is just
happenstance.
After reading Serge's article
http://www.ibm.com/developerworks/db...dm-0510rielau/
on recursion, I see that there are (at least) two ways of achieving a
BOM or similar listing:

1) by depth (as Oracle in the article, or as my set of SPs),
2) by breadth (as DB2 with its' style of recursion using CTE's)
That's the order of the traversal - not the order of the rows in the result
set. Both are very different things and not related to each other.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Oct 16 '06 #7

P: n/a
Knut,

OK - fair comment. What I meant was that the DB2 CTE recursion does
not, by itself, give me a value on which I can later do the sorting
(ORDER BY...) as I wish.

Using a "classical" recursion method (as in my SPs, or as Oracle
manages to do it with its' CONNECT BY clause), where the recursion
works in "depth first" mode, I could arrange to have a counter (IDENT)
field log the position of each row as it is fetched. I can then later
do my sort on this field.

The DB2 CTE recursion method, by "cutting across" the tree-branches as
it skims across each level in succession, does not/cannot correlate the
items in one level to those in the next, and so on. In this case, no
amount of sorting will reestablish the relationships between items in
the original tree.

And that's what I meant - I need the original "organigram" sorting.

Sorry for the confusion,
Rob
On Oct 16, 12:49 pm, Knut Stolze <sto...@de.ibm.comwrote:
robertino wrote:
Knut,
thanks for the input - yes, I'm using exactly the same paramaters.
>>Then you should figure out exactly which ORDER BY clause you need because
that's the _only_ way to ensure a certain ordering of rows in a result
set.
Well, I'm very familiar with the ORDER BY clause (I'm coming from a SQL
Server/MySQL background) but, in this case, you're not right - it's NOT
the only way.Sorry, but it is. The DBMS can return the rows in any way it likes unless
you provide an explicit ORDER BY in your query. Everything else is just
happenstance.
After reading Serge's article
http://www.ibm.com/developerworks/db...dm-0510rielau/
on recursion, I see that there are (at least) two ways of achieving a
BOM or similar listing:
1) by depth (as Oracle in the article, or as my set of SPs),
2) by breadth (as DB2 with its' style of recursion using CTE's)That's the order of the traversal - not the order of the rows in the result
set. Both are very different things and not related to each other.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Oct 16 '06 #8

P: n/a
robertino wrote:
Knut,

OK - fair comment. What I meant was that the DB2 CTE recursion does
not, by itself, give me a value on which I can later do the sorting
(ORDER BY...) as I wish.

Using a "classical" recursion method (as in my SPs, or as Oracle
manages to do it with its' CONNECT BY clause), where the recursion
works in "depth first" mode, I could arrange to have a counter (IDENT)
field log the position of each row as it is fetched. I can then later
do my sort on this field.

The DB2 CTE recursion method, by "cutting across" the tree-branches as
it skims across each level in succession, does not/cannot correlate the
items in one level to those in the next, and so on. In this case, no
amount of sorting will reestablish the relationships between items in
the original tree.

And that's what I meant - I need the original "organigram" sorting.
Now that we got that sorted. Let's get back to debugging your problem.
Did you fire up the SQL PL debugger on it?

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

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

P: n/a
robertino wrote:
Knut,

OK - fair comment. What I meant was that the DB2 CTE recursion does
not, by itself, give me a value on which I can later do the sorting
(ORDER BY...) as I wish.

Using a "classical" recursion method (as in my SPs, or as Oracle
manages to do it with its' CONNECT BY clause), where the recursion
works in "depth first" mode, I could arrange to have a counter (IDENT)
field log the position of each row as it is fetched. I can then later
do my sort on this field.

The DB2 CTE recursion method, by "cutting across" the tree-branches as
it skims across each level in succession, does not/cannot correlate the
items in one level to those in the next, and so on. In this case, no
amount of sorting will reestablish the relationships between items in
the original tree.
I guess your actual question is now: how can I implement depth-first search
with a recursive query? That can be done, for example, in the following
way by exploiting lexicographical ordering:

CREATE TABLE tree (
parent int NOT NULL,
child int NOT NULL,
PRIMARY KEY (parent, child)
)@
INSERT INTO tree
VALUES (1, 1), (1, 2), (2, 5), (5, 12), (12, 13), (2, 6), (6, 14), (6, 15),
(2, 8), (1, 3), (3, 7), (3, 9), (9, 11), (1, 4), (1, 10)@

The tree is this one:

1-+-2-+-5---12---13
| +-6-+-14
| | '-15
| '-8
|
+-3-+-7
| '-9---11
|
+-4
+-10

Query:

WITH r(path, node, level) AS
( SELECT VARCHAR(RTRIM(CHAR(parent)), 32000), parent, 1
FROM tree
WHERE parent = child
UNION ALL
SELECT r.path || '#' || RTRIM(CHAR(t.child)), t.child, r.level+1
FROM r, tree AS t
WHERE r.node = t.parent AND
t.parent <t.child AND
r.level < 10000 )
SELECT node
FROM r
ORDER BY path@

NODE
-----------
1
10
2
5
12
13
6
14
15
8
3
7
9
11
4

That's a nice in-order traversal of the tree. Note that I didn't assume any
ordering of the child nodes for any given parent.

It is also possible to implement the depth-first search traversal in a
different way, i.e. not relying on the sorting of the paths.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Oct 18 '06 #10

P: n/a
Hi Knut,

Yes - I was almost there! - I just hadn't thought about building such a
"path"-string. Here's my version (without the loop- and
overflow-checks):
with mybom (t_eitm, t_comp, t_revi, path, lvl) as

( select distinct eb.t_eitm, eb.t_comp, eb.t_revi,
varchar(rtrim(char(eb.t_eitm)), 2000), 1
from bb.ttiedm110100 as eb
where eb.t_eitm = ' 192100-105'
and eb.t_revi = (select max(t1.t_revi) from baan.ttiedm110100 as t1
where t1.t_eitm = eb.t_eitm)
union all
select xx.t_eitm, xx.t_comp, xx.t_revi, (mm.path || '###' ||
rtrim(char(xx.t_comp))), mm.lvl + 1
from bb.ttiedm110100 as xx,
mybom as mm
where mm.t_comp = xx.t_eitm
and xx.t_revi = (select max(t1.t_revi) from bb.ttiedm110100 as t1
where t1.t_eitm = xx.t_eitm) )

--select distinct path, t_eitm, t_comp, t_revi, lvl from mybom
--order by path

select count(*)
from mybom

which works as expected. I'm beginning to understand this now, so
there's hope for me yet... =)

Thanks,
Rob


On Oct 18, 10:24 am, Knut Stolze <sto...@de.ibm.comwrote:
robertino wrote:
Knut,
OK - fair comment. What I meant was that the DB2 CTE recursion does
not, by itself, give me a value on which I can later do the sorting
(ORDER BY...) as I wish.
Using a "classical" recursion method (as in my SPs, or as Oracle
manages to do it with its' CONNECT BY clause), where the recursion
works in "depth first" mode, I could arrange to have a counter (IDENT)
field log the position of each row as it is fetched. I can then later
do my sort on this field.
The DB2 CTE recursion method, by "cutting across" the tree-branches as
it skims across each level in succession, does not/cannot correlate the
items in one level to those in the next, and so on. In this case, no
amount of sorting will reestablish the relationships between items in
the original tree.I guess your actual question is now: how can I implement depth-first search
with a recursive query? That can be done, for example, in the following
way by exploiting lexicographical ordering:

CREATE TABLE tree (
parent int NOT NULL,
child int NOT NULL,
PRIMARY KEY (parent, child)
)@
INSERT INTO tree
VALUES (1, 1), (1, 2), (2, 5), (5, 12), (12, 13), (2, 6), (6, 14), (6, 15),
(2, 8), (1, 3), (3, 7), (3, 9), (9, 11), (1, 4), (1, 10)@

The tree is this one:

1-+-2-+-5---12---13
| +-6-+-14
| | '-15
| '-8
|
+-3-+-7
| '-9---11
|
+-4
+-10

Query:

WITH r(path, node, level) AS
( SELECT VARCHAR(RTRIM(CHAR(parent)), 32000), parent, 1
FROM tree
WHERE parent = child
UNION ALL
SELECT r.path || '#' || RTRIM(CHAR(t.child)), t.child, r.level+1
FROM r, tree AS t
WHERE r.node = t.parent AND
t.parent <t.child AND
r.level < 10000 )
SELECT node
FROM r
ORDER BY path@

NODE
-----------
1
10
2
5
12
13
6
14
15
8
3
7
9
11
4

That's a nice in-order traversal of the tree. Note that I didn't assume any
ordering of the child nodes for any given parent.

It is also possible to implement the depth-first search traversal in a
different way, i.e. not relying on the sorting of the paths.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany- Hide quoted text -- Show quoted text -
Oct 18 '06 #11

P: n/a
robertino wrote:
Hi Knut,

Yes - I was almost there! - I just hadn't thought about building such a
"path"-string. Here's my version (without the loop- and
overflow-checks):
with mybom (t_eitm, t_comp, t_revi, path, lvl) as

( select distinct eb.t_eitm, eb.t_comp, eb.t_revi,
varchar(rtrim(char(eb.t_eitm)), 2000), 1
from bb.ttiedm110100 as eb
where eb.t_eitm = ' 192100-105'
and eb.t_revi = (select max(t1.t_revi) from baan.ttiedm110100 as t1
where t1.t_eitm = eb.t_eitm)
union all
select xx.t_eitm, xx.t_comp, xx.t_revi, (mm.path || '###' ||
You want want to choose a shorter separator like just a single '#'. Then
the path is probably not as easily readable, but it is shorter - that gives
you a bit more leeway regarding the depth of the traversal.
rtrim(char(xx.t_comp))), mm.lvl + 1
from bb.ttiedm110100 as xx,
mybom as mm
where mm.t_comp = xx.t_eitm
and xx.t_revi = (select max(t1.t_revi) from bb.ttiedm110100 as t1
where t1.t_eitm = xx.t_eitm) )

--select distinct path, t_eitm, t_comp, t_revi, lvl from mybom
--order by path

select count(*)
from mybom

which works as expected. I'm beginning to understand this now, so
there's hope for me yet... =)
--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Oct 19 '06 #12

P: n/a
Knut,

Yes, good tip - but I chose the longer separator for readability, since
I know that the maximum level-depth of our BOMs (trees) stands at 12 at
the moment, and each parent/child has a maximum length of 47 bytes.
This gives me a total maximum record-size of less than 1kB, easily
manageable in our 4kB page-size environment.
Serge,

I wrote a reply and sent it off, but the d***ed thing flew into orbit
or somewhere. So, no, I haven't yet debugged the monster coz I've a
bunch of Windoze programming to finish off AND I still haven't yet got
to grips with the Dev Center. Maybe next week.

How's the IOD?

Rob

On Oct 19, 8:32 am, Knut Stolze <sto...@de.ibm.comwrote:
robertino wrote:
Hi Knut,
Yes - I was almost there! - I just hadn't thought about building such a
"path"-string. Here's my version (without the loop- and
overflow-checks):
with mybom (t_eitm, t_comp, t_revi, path, lvl) as
( select distinct eb.t_eitm, eb.t_comp, eb.t_revi,
varchar(rtrim(char(eb.t_eitm)), 2000), 1
from bb.ttiedm110100 as eb
where eb.t_eitm = ' 192100-105'
and eb.t_revi = (select max(t1.t_revi) from baan.ttiedm110100 as t1
where t1.t_eitm = eb.t_eitm)
union all
select xx.t_eitm, xx.t_comp, xx.t_revi, (mm.path || '###' ||You want want to choose a shorter separator like just a single '#'. Then
the path is probably not as easily readable, but it is shorter - that gives
you a bit more leeway regarding the depth of the traversal.
rtrim(char(xx.t_comp))), mm.lvl + 1
from bb.ttiedm110100 as xx,
mybom as mm
where mm.t_comp = xx.t_eitm
and xx.t_revi = (select max(t1.t_revi) from bb.ttiedm110100 as t1
where t1.t_eitm = xx.t_eitm) )
--select distinct path, t_eitm, t_comp, t_revi, lvl from mybom
--order by path
select count(*)
from mybom
which works as expected. I'm beginning to understand this now, so
there's hope for me yet... =)--
Knut Stolze
DB2 Information Integration Development
IBM Germany- Hide quoted text -- Show quoted text -
Oct 19 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.