SELECT qry1.fld1 As FirstField, qry1.fld2 As SecondField, qry2.fild2 as
ThirdField
FROM qry1 INNER JOIN qry2 ON qry1.Field1=qry2.fld1
ORDER BY FirstField

         select ... into cursor one

         select ... into cursor two

         select one.*,two.*
         from one full outer join two on one.pk=two.pk
with suitable changes for DBMS and table and column names.

Sincerely,

Gene Wirchenko

CREATE TABLE #a (Idx INT NOT NULL PRIMARY KEY,
Val INT NOT NULL)

CREATE TABLE #b (Idx INT NOT NULL PRIMARY KEY,
Val INT NOT NULL)

INSERT INTO #a (Idx, Val)
SELECT 1, 12
UNION SELECT 2, 34
UNION SELECT 3, 45

INSERT INTO #b (Idx, Val)
SELECT 1, 34
UNION SELECT 2, 44
UNION SELECT 3, 98

SELECT a.Idx, a.Val, b.Val
FROM #a a
INNER JOIN #b b
ON a.Idx = b.Idx
ORDER BY a.Idx

DROP TABLE #a
DROP TABLE #b

If I understand the question, my vote goes to Piet's solution. If you have
unmatched rows in either Query, then you'd need something a bit different.

Larry Linson
Microsoft Access MVP

Hang on a minute... I guess my answer was a bit premature before.  What
database are you using to do this?  If you're using Oracle, you can use
a full outer join and PL/SQL to do it.

If you're using Access, it's a different kettle of fish, because Access
doesn't support full outer joins.

So end the suspense.  What database are you doing this in?  (Or just
target your post to the relevant database group).  The answer will
largely depend on that, since Oracle, Access, SQL Server, and DB2 all
have their own implementations of the SQL92 standard...

This is not a table; the rows of a table model elements of a set of the
same kind of thing.  What you want is a display kludge to show, say,
automobiles and squid as if they were the same kind of things.

Here is your kludge, since people here often gripe that I do not post
the bad code the OP wants:

SELECT *, ROW_NUMBER() OVER(ORDER BY duh) AS lft_nbr
FROM Foo
FULL OUTER JOIN
SELECT *, ROW_NUMBER() OVER(ORDER BY doh) AS rgt_nbr
FROM Bar
ON Foo.lft_nbr = Bar.rgt_nbr;

The right way is handle display issues in the applications and front
ends, not the RDBMS.