×
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.
Note: If the SQL summary ran soon after the Read or FETCH scenario,
that may skew the results, such that the SQL summary was artificially
small length of time. Regardless...
If I understand the scenario described, and the resultant question, I
think the typical analogy of documents in folders in a file cabinet,
suffices to explain how the data on those documents could be summarized.
The SQL summarization:
Approach and open the cabinet full of folders, directly page
through all the documents in each folder to summarize. Optionally the
individual folders could be distributed amongst multiple people working
concurrently to perform the summary of all documents in each folder.
The SQL FETCH or RPG READ with program summarization:
Have someone else approach and open the cabinet full of folders,
have that person deliver all of the folders in separate trips to your
desk. Sequentially summarize documents in each folder; after each is
completed request the next folder, the prior folder is returned, and
repeat until all folders are processed. Because any one folder may
contain so many documents, many more than one trip per folder may be
required.
In either case, if each folder does not already represent a GROUP,
then the processing includes regrouping the documents by division into
each summarization. In the latter case the person sent to get the
folders must first do that collation, before returning the first folder.
In the former case, collation can occur at the cabinet as well, but
concurrently with summarization, rather than being completed before
summarization starts.
The key difference is /data movement/. The former requires minimal,
[effectively no] movement of data, except the final summarized results
for each folder. The latter requires passing all of the documents
somewhere else to perform the summary; depending on the requirements
each document may be a copy which need not be returned or the original
which must be returned to the cabinet.
Regards, Chuck
D Reaper wrote:
I have a very basic question concerning SQL. Can someone point me
to information on how SQL accesses data on the iSeries? What are
the underlying mechanics of the process?
Last week I was made aware of a sales related inquiry that was taking
many minutes to produce data. The purpose of the inquiry is to
display sales summarized by division (12 of them). There are about
1.5 million records in the file, each record is 300 bytes long. There
are no logical files built on this physical file.
The program was written using embedded SQL with the fetch option. The
program does nothing else but load an array with summary data and
then display it using a subfile after all the data is read.
For testing purposes, I also wrote a version using the RPG read
option. Both of these options ran about the same time, about 9
minutes. I also tried using the RUNSQLSTM, this ran in 9 seconds.
The time differences are amazing. How does SQL process all this data
in less then 9 seconds? I understand there are differences in how SQL
and RPG are implemented, but it seems a large difference.
Are there any books, papers, articles, that show how SQL access data
on the iSeries? How does it work with DB2, the OS, and the hardware
to deliver data?
midrange.com
