×
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 2/24/11 9:20 PM, Birgitta Hauser wrote:
Why you want to access an SQL view with native I/O?
The OP for the thread may or may not have a good reason, but...
Same reason someone might use an unordered OPNQRYF. I have done so
for CLP RCVF many times, minimally to accomplish either what DDS LF does
not [e.g. certain CAST, and CASE] or to provide dynamic selection
[CREATE VIEW QTEMP/myView ... WHERE selection specific to this job].
FWiW CPYF of a VIEW is native
An SQL view has no relative record no., nor a predefined
sequence.
Order is not always relevant. In utilities I often used OPNQRYF and
then eventually SQL to generate strings that were CL commands such as
RMVM or DLTxxx from output file data obtained from DSPFD *MBR or
DSPOBJD. When order matters, KEYFLD() on OPNQRYF was still required.
However the SQL was still nicer generally, so typically I would generate
a VIEW definition instead of the so-often more complex OPNQRYF parameter
specifications, and then issue OPNQRYF KEYFLD() against the VIEW to
effect the required ordering.
In this way it is not possible to position at the beginning.
The common data management and database seem to do just fine with
POSDBF for both *START and *END for POSITION(), regardless that the
access path is neither "keyed" nor literally "arrival"; access is always
"sequential". IIRC RRN positioning was directed to the primary file for
the query causing possible positioning to rows that are not accessible
to the VIEW [per <join\where> selection] instead of CPF4276 rc4 having
prevented the request, thus resulting in positioning errors; I recall
JHHL had recorded such a problem I believe on the Midrange-L and the
MI400-L.
When accessing the file with embedded SQL, it is possible to
predefine a sequence by adding an order by.
Accessed by RLA, rows that have been READ into an array, for example,
could then be sorted. One need only understand that the set defined by
a query encapsulated in the VIEW has no specific collation, for lack of
[any ability to specify an] ORDER BY. But as noted above, the native
can get order from a VIEW using OPNQRYF KEYFLD() LANGID() SRTSEQ()
Also closing and reopening the cursor will position your view at the
first row returned in the result set.
And a new OPNDBF could effect the same for native, but very expensive
when compared to POSITIONing to *START. To ensure nearer to "live
data", the new open may be effectively required to access what might be
a new *START; no clue really, I do not recall the implementation over a
query ODP, as I have mostly used static data and have never looked into
cases of since-deleted and\or new rows when accessing active data.
Regards, Chuck
midrange.com
