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



This is a personal choice, I know. It helped me a lot when I switched to this, so I pass it on for whatever it might be worth to you:

First, deprecate the READC solution. That was useful way back when we had 300 baud modems, but today it is just one more place you can develop unexpected errors (like this one, right now.)

Second, use a for/endfor loop for the sfl chain. Much cleaner code.

c for sfl1rrn = 1 to sflsize
c sfl1rrn chain sfl1
c....
c endfor

Third, store the original data in the sfl record as hidden data so that you can check for changes right there, and you can refresh the subfile right from the sfl record itself, if the user requests it. If you are updating data files it is easy to tell if the original record has been changed in the meantime at another work station. Plus, if the user changes the field and then changes it back to the original, you aren't making false changes.

Please accept this in the manner intended. It saved me pots and pots of trouble, so I want to share it. But it is most certainly a personal choice.

On 9/30/2010 4:27 PM, Paul Tuohy wrote:
Hi Scott,

Hate to disagree, but you should not need to display the subfile for the
subsequent READC to work.

The technique I have always used with "load all subfiles" is to perform
a validation pass over a subfile (using a READC loop) and update each
subfile record with SFLNXTCHG set. If any record is invalid, the subfile
is re-displayed. Otherwise, another READC loop is performed - without
any interim reference to the subfile control record.

Only difference I see here is that a CHAIN is being used on the first
read through the subfile.

Regards

Paul Tuohy
ComCon
www.comconadvisor.com
www.systemideveloper.com





Scott Klement wrote:
hi Florin,

After marking the records changed (with the indicator for SFLNXTCHG) you
need to display the subfile before READC will see that the records are
changed.

When I do something like this, I typically will use the WRITE opcode to
redisplay the SFLCTL record without waiting for user input. That way, I
can go ahead and start reading them immediately.


On 9/30/2010 2:18 PM, Florin Todor - YYZ Concord wrote:

Hello,



I have an issue, which, in my opinion shouldn't be an issue at all
because it is pretty straight forward...



Anyway, I have a subfile where I need to check (for ALL records) if a
specific field has a certain value. I do this using CHAIN RRN op-code.
I, also, want to make EVERY record available for the next READC
operation; pretty simple, right? The only problem is it doesn't work!
The READC does not see any "changed" record...



Here is the relevant code:



C sr_chkhaz begsr

/Free

s1rrn = 1;

Dow s1rrn<= 30 and

v_hazfrt = 'N';

Chain s1rrn R010D02;

If %found();

If #DHAZ = 'X' or

#DHAZ = 'H';

v_hazfrt = 'Y';

Endif;

*in37 = *on;

Update R010D02;

*in37 = *off;

Endif;

s1rrn += 1;

Enddo;

s1rrn = 1;

Write R010D03;

/End-free

C endsr



*in37 turns on/off SFLNXTCHG for R010D02 Subfile record:



A R R010D02 SFL

A 37

AO 69 SFLNXTCHG





The excerpt of the main program:



......................................................



C exsr sr_chkhaz

C move *off *in35

C *in35 doweq *off

C readc r010d02 35
<<<<<<----------*in35 is turned *on

C *in35 ifeq *off



........................................................................
.............





Any thoughts?







Thank you





Florin Todor



<mailto:ftodor@xxxxxxxxxxxxxxxx>







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.