Display rows into multiple columns

Question

I have a table in the following format:
id value
a1 0
a2 0
a3 0
a4 0
b1 0
b2 0
b3 0
b4 0
how do I go about displaying it into four columns in the following format:
id1 value1 id2 value2
a1 0 b1 0
a2 0 b2 0
a3 0 b3 0
a4 0 b4 0

Answer 1

Hi,
789063 wrote:
I got that error in toad. So now I am testing from command prompt. When you say "command prompt", do you mean SQL*Plus?
Sorry, I don't know much about Toad. If Toad is returning 0 rows, and the same query is returning 8 rows in SQL*Plus, then I suspect you are not connecting to the same database or the same user. ASre you sure you're running the exact same query in both front ends?
Here is the data set that I am testing for:
<pre>
id1 value
smple_val_1 0
smple_val_2 1
smple_val_3 1
smple_val_4 2
smple_other_1 3
smple_other_2 5
smple_other_3 8
smple_other_4 13
some_other_val1 1
some_other_val2 0
some_other_val3 3
some_other_val4 5
</pre>
I am trying to select only 'smple%' in the query, which should display in four columns like:
<pre>
id1 val1 id2 val2
smple_val_1 1 smple_other_1 3
smple_val_2 0 smple_other_2 5
smple_val_3 0 smple_other_3 8
smple_val_4 2 smple_other_4 13
</pre>Is that really the output you want? Why not
ID1             VAL1 ID2             VAL2
smple_val_1        0 smple_other_1      3
smple_val_2        1 smple_other_2      5
smple_val_3        1 smple_other_3      8
smple_val_4        2 smple_other_4     13with the 0's and 1's in the val1 column reversed?
Here is the ddl I used:
<pre>
CREATE TABLE     table_x
( id     VARCHAR2 (20)     PRIMARY KEY
, value     NUMBER
INSERT INTO table_x (id, value) VALUES ('smple_val_1', 0);
INSERT INTO table_x (id, value) VALUES ('smple_val_2', 1);
INSERT INTO table_x (id, value) VALUES ('smple_val_3', 1);
INSERT INTO table_x (id, value) VALUES ('smple_val_4', 2);
INSERT INTO table_x (id, value) VALUES ('smple_other_1', 3);
INSERT INTO table_x (id, value) VALUES ('smple_other_2', 5);
INSERT INTO table_x (id, value) VALUES ('smple_other_3', 8);
INSERT INTO table_x (id, value) VALUES ('smple_other_4', 13);
INSERT INTO table_x (id, value) VALUES ('some_other_val1', 1);
INSERT INTO table_x (id, value) VALUES ('some_other_val2', 0);
INSERT INTO table_x (id, value) VALUES ('some_other_val3', 3);
INSERT INTO table_x (id, value) VALUES ('some_other_val4', 5);
</pre>Thanks, that's good.
Where is the explanation of how you get the results you want from that data? There are a lot of different ways to get the same results from the same data, especially from a small set of sample data. I might provide a query that gets the right results for the wrong reasons, and when you run that query on a different set of data, it won't necessarily work. That's exactly what happened before. I guessed at what you wanted, but I guessed wrong. Guessing is not a very efficient or reliable way to solve problems. Don't make people guess: explain what you want.
In particular, explain how you can tell, buy looking at a row and column in the original table, to which row and which column of the output it corresponds. I'm pretty sure that the id column of the table always corresponds to either the id1 or idl2 column of the output, and that value always corresponds to either val1 or val2. From this latest set of sample data, it looks like all the rows in table_x that start with 'smple_val' will correspond to the id1 and val1 columns, and that all therows that start with 'smple_other_' will correspond to the id2 and val2 columns. It also looks like each row of the output represents a unique value of the last character of table_x.id.
If I guessed right this time, then what you want is:
SELECT       MIN (CASE WHEN id LIKE 'smple\_val\_%'   ESCAPE '\' THEN id    END)     AS id1
,       MIN (CASE WHEN id LIKE 'smple\_val\_%'   ESCAPE '\' THEN value END)     AS val1
,       MIN (CASE WHEN id LIKE 'smple\_other\_%' ESCAPE '\' THEN id    END)     AS id2
,       MIN (CASE WHEN id LIKE 'smple\_other\_%' ESCAPE '\' THEN value END)     AS val2
FROM       table_x
GROUP BY  SUBSTR (id, -1)
ORDER BY  SUBSTR (id, -1)
;But this is only a guess. I can't guarrantee that this will work on your real data any better than my last guess did. You'll get better answers faster if you provide an explanation, so that poeple don't have to guess so much.