Skip to main content

What happens in the program flow after DISCARD?

  • January 12, 2026
  • 2 replies
  • 59 views
Ingo Stiller
Forum|alt.badge.img+3

Hi Freaks

It seems to me that whith every new UnifAce-Version the behavior of DISCARD change

If the DISCARD in the READ-trigger itself the UnifAce engine
a) recall the READ-trigger (very old Uniface versions, result sometime to an stack overflow)
b) starts the READ-trigger again (current UnifAce versions)

But we do have a globale procedure to execute the read.
In this case UnifAce 
a) steps to the next statement (if then is no more to read)
b) leaves all procedures and return to the READ-trigger
c) restart the current procedure. Sic! (with 10.4.3.032?)
    [i.e. cleans all variables and starts the procedure just at the begin.]
I’m not sure with which version the behavior change from b) to c) or if there was other “reaction” in between


Testing our product under UF10.4.03.32 leads to crashes when retrieving and/or sorting hitlist with rows to discard (due to right managament)
The same routines in the old environment works perfect.

Does some else do have DISCARDS in subroutines (called direct or indierect from the READ-trigger)?
Do you have also “problems” when retrieving/sorting hitlist?
@UnifAce: Did there something change how UnifAce handels DISCARDS?

Ingo

 

 

2 replies

Ingo Stiller
Forum|alt.badge.img+3
  • Ingo Stiller
  • Author
  • Participating Frequently
  • January 13, 2026

BTW: After creating workaroun, the crash behavior seemed to have been eliminated. But as soon as a few debug messages were added, UnifAce crashed again.
Without any further steps after DISCARD ($proc_tracing=1) and without a stack overflow.
So DISCARD was isolated again and the following procedure was written. Now it looks stable.
 

$43 = “”
Call LLP_DISCARD2
…

ENTRY LLP_DISCARD2
IF($43!=””) RETURN
$43=”X”
discard
END

 

Peter Beugel
Forum|alt.badge.img+1
  • Peter BeugelRocketeer
  • Rocketeer
  • February 6, 2026

Hello Ingo

 

If you think something is wrong with discard you should log a casewith Uniface support.

The last fix done in 10.4.03-010 is 

UNI-41736 Discard in read trigger can cause '9033 - proc stack overflow' in 10.4.03

 

There is page with a ot off information in the Uniface library:

discard

 

The new AI developer assistent suggests for discard outside read

function discardAndFetchNext
    clear/e "ENT1"
    retrieve/e "ENT1"
    setocc "ENT1", 1

    repeat
        selectcase P1.ENT1
            case "1"
                ; Process the occurrence
                putmess "Processing occurrence: ", $curocc(ENT1)
                
                ; Discard and ensure next is fetched
                discard
                if ($status = 0) then
                    setocc "ENT1", $curocc(ENT1) + 1
                endif

            case "10"
                ; Process the occurrence
                putmess "Processing occurrence: ", $curocc(ENT1)
                
                ; Discard and ensure next is fetched
                discard
                if ($status = 0) then
                    setocc "ENT1", $curocc(ENT1) + 1
                endif

            elsecase
                ; Handle other cases or exit loop
                putmess "No more relevant occurrences."
                leave
        endselectcase
    until ($status <= 0)
end
 

 

A related workaround if this causes problems

 read
 if ($status>=0)
    if ($filter$)
       call filter
       if ($remove$)
        discard
       endif
    endif
 end
 
 entry discardtest
 clear/e "ENT1"
 $filter$="T"
 retrieve/e "ENT1"
 setocc "ENT1",1
 repeat
 setocc "ENT1", $curocc(ENT1) + 1
 until ($status <0)
 $filter$="F"
 $remove$="F"
 end
 
 entry filter
 
 selectcase P1.ENT1
 case "1"
    $remove$="F"
 case "10"
    $remove$="F"
 elsecase
    $remove$="T"
 endselectcase
 end

 

 

 

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement