× 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.



You really know how to put someone down and make them feel stupid don't
you. But please don't twist my words... I didn't say it was "complicated
to me", just said "more complicated than it needed to be". Big
difference. I can do it, however, I have to think about the other
programmers here that it might not be able to understand all that.

On Tue, Dec 30, 2014 at 4:09 PM, Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
wrote:

Michael,

Ahh, I see... you are thinking of using "dynamic" arrays (i.e. allocating
only part of the array using pointer logic) and this seems complicated to
you.

Honestly, I had realized that you were talking about that... I would
discourage using that approach. I would just use a normal array of data
structures -- it could even use LIKEREC to have a structure with the same
layout as the subfile.

The OP said that each record was 400 bytes long, and that it usually
wouldn't be larger than 50 records needed. As such, the amount of memory
used here is totally insignificant... no need to make it dynamic. (Heck,
even if you made it 1000 records, it's not a big deal memory-wise.)

Seems to me this is simpler than a file. No need to create an object, no
need to read/write from an object... just copy into an array. Not only is
it much faster, but the code is also simpler.

-SK



On 12/30/2014 2:58 PM, Michael Schutte wrote:

So okay, time to think about it. I was short with my response. My
intention wasn't to give the OP the answer nor to give him something that
he might not be as familiar with. To me the easier option for the OP to
use
a temporary table (QTEMP). This was based on the OP asking "where's a
linked list when we really need it?" That said to me that they were not
as
familiar with RPGLE arrays. (Assumption, I know, makes an a## out of me).

Sure writing and reading from disk would take a little bit more time, but
really what are we talking about with the power of these systems these
days?

You are right, arrays are not limited too 9999, in the haste of my
response
I did not clarify that. However, they are limited! Not sure the exact
number but they are unless you venture into dynamic arrays. I have
attempted to do that once, however, I felt it was far more complicated
than
it needed to be. Hence a QTEMP table.


On Tue, Dec 30, 2014 at 3:19 PM, Michael Schutte <mschutte369@xxxxxxxxx>
wrote:

Of course it was, it was just a point. not that stupid!

On Tue, Dec 30, 2014 at 3:17 PM, Scott Klement <
midrange-l@xxxxxxxxxxxxxxxx> wrote:

Michael,

Arrays are not limited to 9999 records.

Perhaps you are referring to the limit of the size of a subfile? But,
then, this wouldn't be a reason to store the data in a file in QTEMP...
it'd merely be a reason to write a page-at-a-time subfile (which could
be
loaded from an array just as well as a file.)

My understanding is that this thread was about inserting a record into
the middle of a subfile. To me, that's a very different question than
"how
do I have more than 9999 rows in a subfile".




On 12/30/2014 2:08 PM, Michael Schutte wrote:

Or because you have more than 9999 records

On Mon, Dec 29, 2014 at 4:57 PM, Scott Klement <
midrange-l@xxxxxxxxxxxxxxxx>
wrote:

Load your subfile into an array in your program, then clear the
subfile,

and reload it from the array, inserting the new row(s) where needed.

This is very easy, and runs very fast. I can't see any good reason
to
use a file (in QTEMP or otherwise) that would only hurt performance.
Unless, of course, you need to do that because you need it saved to
disk...


On 12/29/2014 3:39 PM, x y wrote:

I need to insert records into the middle of a subfile. The user can

enter
a keyword that's attached to a long description and I need to get
that
description into the body of the subfile.

I could add records to the end and then resequence when writing to
the
database but that won't be satisfactory from a user experience
perspective--the user needs to see the full text in order as part of
the
entry process. My subfile record length (including hidden fields) is
about
400 bytes and I should have less that 50 records most of the time. I
have
four 132-character subfile records on the screen and already have
used
the
fold/unfold option.

Copying the subfile to a variable-size array, inserting the records
where
needed, and then reloading the subfile is an option.

Another option is to have A/B subfile control/detail set up records
copy
from the "A" subfile (+ inserts) into the "B" subfile and then
display
the
"B" control record. SQL temporary tables and memory-resident tables
are
possibilities also.

Where's a linked list when we really need it?

I'll be grateful for any suggestions and wish you all a Happy New
Year.

thx...

--

This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.