× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 22-Mar-2014 00:55 -0700, Birgitta Hauser wrote:
CRPence on Friday, 21.3.2014 21:51 wrote:

On 21-Mar-2014 12:41 -0700, Stone, Joel wrote:

I would like to select 5 rows (of thousands) where field1 = 'A'
and union that with 5 rows where field1 = 'B'

How can I accomplish this with SQL?

I have tried variations of

select * from file1
where field1 = 'A'
FETCH FIRST 5 ROWS ONLY
union
select * from file1
where field1 = 'B'
FETCH FIRST 5 ROWS ONLY


To use the FETCH ... ONLY clause in that context, the subquery
must be a derived table expression; e.g. a Nested Table Expression
(NTE). <<SNIP>>

This rule was removed with release 6.1, i.e. FETCH FIRST x ROWS
and ORDER BY can be directly used within a Sub-Select. But the
Sub-Select must be enclosed in parentheses.
The following statement works on Release 7.1 without any problem:

( Select *
from MyTable
Where MyField1 = 'A'
Order By MyField2 Desc
Fetch First 5 rows only
)
Union
( Select *
From MyTable
Where MyField1 = 'B'
Order By MyField2 Desc
Fetch First 5 Rows Only
)
;

And even the following statement works without any problems:

( Select *
from MyTable
Where MyField1 = 'A'
Order By MyField2 Desc
Fetch First 5 rows only
)
Union
( Select *
From MyTable
Where MyField1 = 'B'
Order By MyField2 Desc
Fetch First 5 Rows Only
)
Order By MyField2, MyField1
;


I was actually aware of that, but I can not test anything beyond v5r3 :-( I should have clarified that the restriction I had noted, was known to exist for that earlier release, and I should have offered additionally, what I expected would be valid [though untested] in newer releases. Yet, there was no mention of the available VRM in the OP. So, that the code I offered operates within the limitations of older releases as well as on newer releases, makes my examples functional for a wider audience :-)

Unfortunately I chose to be curt and was being somewhat cynical in my reply, because I recalled offering up effectively the same reply as quoted just above, in the recent past topic "Subject: SQL UNION and ORDER BY" <http://archive.midrange.com/midrange-l/201402/msg00330.html#> by the same OP; FWiW, the above reply makes an even better conclusion to what is in that earlier thread. However I just checked, and noticed that my reply was never sent [found the message in my /drafts/ folder], either because my system crashed [e.g. per power loss, as I have no battery] or I had decided your reply <http://archive.midrange.com/midrange-l/201402/msg00346.html> was sufficient. But I see now, in review [rather than depending solely on my recollection], that discussion did not include the FETCH FIRST clause, just ORDER BY. Consider my smirking expression erased, replaced with that of shame.

FWiW: I expect the UNION shown in the example from the OP as one of the "variations" tried, does not express an explicit intent. The original UNION [DISTINCT] was replaced by a UNION ALL in my reply [though snipped], because the expressed requirements seem not to want to effect distinct processing on the results of each subquery. Thus there would seem no reason to effect de-duplication of those two sets via distinct processing on the overall result set; i.e. while fewer than "5 rows" may result naturally due to a lack of that many matching rows, fewer than five rows resulting instead due to distinct processing would seem to vitiate the expressed requirements. And if each of the combined sets are already naturally distinct, then any work to perform distinct processing on the overall result set, would be unnecessary overhead.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.