Question Question on progress procedure mode

[BobyIsProgress]

Hello,

I'm running progress OE11 and have a question.
I have a program that is used to keyed scrap movement. It work like this:
1. First procedure we add movement to our Movement table
2. We logged the scrap in our scrap table

While this another app is running on the same prowin32 and do automatic refresh.
I know that progress is procedural and while follow, but is it possible that the refresh could interfere with the initial procedure like this:
1. First procedure we add movement to our Movement table
Automatic refresh
2. We logged the scrap in our scrap table

Thanks in advance,

Best Regards,

BobyIsProgress

 

[Stefan]

Yes, even though the AVM is single-threaded and events will only fire based on actions, ie not automatically, pstimer can be used to sprinkle events around that occur while another program is running and which could do anything disruptive.

 

[BobyIsProgress]

Is there a way to know that something is already running and blocked the timer or to replace it by something else ?

 

[BobyIsProgress]

Also, is there other think that can interrupt a procedure, and I'm not talking about "LEAVE" or "RETURN" and other progress keywords.
I'm a bit at loss on this matter, 99.99% of a time my procedure run smoothly, but 0.01% goes wrong . And I don't know why. They did the same process on the same product 1min or less after and all goes good ..

 

[tamhas]

A clear explanation of what you want or what you are trying to fix would help.

 

[BobyIsProgress]

So to take it from the start, we have a program that register scrap information in two steps:
1. Register all scrap movement on the movement table
2. Register complementary data on the scrap table
This process work 99.99% of the time.

But for some reason in 0.01% of the time we have
1. Register all scrap movement on the movement table
2. Step 2 doesn't occur at all, and I know that because I have 0 records matching my scrap movement

This two steps are run in the same Trigger Button.
I try to solved that and maybe find the root of this issue.
I have in the background a dashboard that is refreshed automatically by a Pstimer.

 

[Jean-Christophe Cardot]

Hi
Can't you stop the pstimer during the process? You stop it at the beginning of 1, then restart it at the end of 2.
no?

 

[TomBascom]

So you have a procedure similar to the following:

procedure doStuff:

  /* register scrap movement */

  do transaction:
    for each tt_scrap:
      buffer-copy tt_movement to movement.
    end.
  end.

  /* register complementary data */

  do transaction:
    for each tt_complement:
      buffer-copy tt_complement to complement.
    end.
  end.

end.

And you think that _maybe_ something might happen somewhere between those two blocks that prevents the 2nd block from running?

"similar" in that there are two distinct blocks of code "registering" some changes. I am pretending that the pending changes are in two distinct temp tables and that "registering" them means copying them to real tables. Your actual code might do something else...

 

[TomBascom]

If I had to guess I will guess that your "refresh" procedure does something that clears the pending complementary changes.

 

[tamhas]

Why not just put both updates within the same transaction ... and, turn off pstimer and any possible user input while running that transaction?

 

[BobyIsProgress]

Sorry for the late answer all

@TomBascom this is maybe a more detail structure of what is down:

RUN SCRAP-MOVEMENT.

RUN LOG-SCRAP-DATA .


PROCEDURE SCRAP-MOVEMENT:
 
     FOR EACH TTSCRAP NO-LOCK:
        do something with a closed code include file (closed code by the editor)
    END.
END.

PROCEDURE LOG-SCRAP-DATA:
    DEFINE BUFFER upd-SCRAP FOR SCRAP.
    FOR EACH TTSCRAP NO-LOCK:
        DO FOR upd-SCRAP TRANSACTION:
            CREATE upd-SCRAP.
            Assigning value
        END.
    END.
END.

My guess is that the pstimer somehow manage to disrupt the process.
At the moment I tried a solution like this:

DO TRANSACTION:
       RUN SCRAP-MOVEMENT.

       RUN LOG-SCRAP-DATA .
END.


PROCEDURE SCRAP-MOVEMENT:
 
     FOR EACH TTSCRAP NO-LOCK:
        do something with a closed code include file (closed code by the editor)
    END.
END.

PROCEDURE LOG-SCRAP-DATA:
    DEFINE BUFFER upd-SCRAP FOR SCRAP.
    FOR EACH TTSCRAP NO-LOCK:
        DO FOR upd-SCRAP TRANSACTION:
            CREATE upd-SCRAP.
            Assigning value
        END.
    END.
END.

In the psTimer tick trigger:

IF TRANSACTION THEN RETURN.
ELSE run refresh .

@tamhas it's one of the possibility . I just try to understand the root of this to know if I have to find another solution of the psTimer for other program.

Best Regards

 

[ShubhamSingh]

In a Progress OpenEdge environment where multiple applications are running concurrently, it is possible for automatic refreshes or background processes to interfere with the sequential execution of your procedures. However, the extent of interference would depend on the specific implementation and configuration of your applications.

If the automatic refresh process is reading or updating the Movement table or the scrap table while your initial procedure is still in progress, it could potentially cause conflicts or unexpected behavior. This interference can manifest as data inconsistencies, conflicts in record locking, or incorrect results.

To mitigate such interference, you can consider implementing proper locking mechanisms and transaction management in your application. Progress OpenEdge provides various locking techniques, such as record-level locking and table-level locking, which can help prevent conflicts when accessing shared data.

Additionally, you can utilize transaction boundaries to ensure the atomicity and consistency of your operations. By encapsulating related database operations within a transaction, you can maintain data integrity and isolate your changes from concurrent processes until the transaction is committed.

It is also essential to review the automatic refresh mechanism in your application. Assess whether it can be configured to avoid interfering with critical operations like adding movement to the Movement table or logging scrap in the scrap table. Adjusting the refresh frequency or scheduling it during idle periods might help minimize potential conflicts.

Overall, while it is technically possible for automatic refreshes or background processes to interfere with your initial procedure, careful consideration of locking, transaction management, and configuration settings can help mitigate such issues and ensure the smooth operation of your application.

 

[BobyIsProgress]

Hello Thank you for your advice.
I will see what I can do about it.

Best Regards,

BobyIsProgress