Error Not Commited To Db

Densi Prabath

New Member
in my program there is process, it running ruffly 3 hours. In the middle of this process. I have give warning message to user when error data trying to update to db and avoid it.
one day it proceed and process executed nicely,my waning message also occurred. At last there is message "Successfully completed".But at that day it not appeared. I checked out with database.Any data not update to db.I have checked .lg file.there also record.But all data missing.
Have you any idea about that issue ?
Thank you.
progress 9.1c
windows server 2003
 

Cringer

ProgressTalk.com Moderator
Staff member
Without seeing your code we won't be able to help. Your description is rather vague as well.
And 9.1c is hopelessly old and out of date.
 

Densi Prabath

New Member
Without seeing your code we won't be able to help. Your description is rather vague as well.
And 9.1c is hopelessly old and out of date.
there are 4036 line of code and also lot of external procedures.
i have attached some code.
there is massage "Invalid <Transaction No> ".that massage came during the process.
thank you.


Code:
DEFINE SHARED VARIABLE mSysDate     AS DATE.
DEFINE SHARED VARIABLE loginname    AS CHARACTER.
DEFINE SHARED VARIABLE Mbranch      AS CHARACTER.

DEFINE INPUT PARAMETER  ipAccNo     AS CHARACTER.
DEFINE INPUT PARAMETER  ipTrNo      AS CHARACTER.
DEFINE INPUT PARAMETER  ipUsrApp    AS CHARACTER.
DEFINE OUTPUT PARAMETER opUpdStat   AS LOGICAL INITIAL FALSE.


DEFINE VARIABLE mSerialNoSt AS INTEGER    NO-UNDO.
DEFINE VARIABLE mSerialNoEn AS INTEGER    NO-UNDO.

DEFINE VARIABLE winSerial AS CHARACTER  NO-UNDO.
DEFINE VARIABLE mSERTIME AS CHAR .

ASSIGN mSERTIME = STRING(TIME,"HH:MM:SS").

DO TRANSACTION:
    FIND FIRST fixdepo.FIX_MAST WHERE FIX_MAST.DEP_NO = ipAccNo EXCLUSIVE-LOCK NO-ERROR.
    IF AVAILABLE FIX_MAST THEN
    DO:
        FIND FIRST ACC_LOG WHERE ACC_LOG.AC_NO = ipAccNo AND
                                 ACC_LOG.TR_NO = ipTrNo    USE-INDEX AC_NO_TR_DAT EXCLUSIVE-LOCK NO-ERROR.
        IF AVAILABLE ACC_LOG THEN
        DO:
            IF ACC_LOG.TR_STAT <> "A" THEN
            DO:
              
            END.
            ELSE
            DO:
                MESSAGE "<Transaction> Already Approved by "  TRIM(ACC_LOG.USR_APROVED)VIEW-AS ALERT-BOX QUESTION BUTTONS OK TITLE "InBank Information System".
            END.
        END.
        ELSE
        DO:
            MESSAGE "Invalid <Transaction No> " ipTrNo VIEW-AS ALERT-BOX QUESTION BUTTONS OK TITLE "InBank Information System".
        END.
    END.
    ELSE
    DO:
        MESSAGE "Invalid <Account No> " ipAccNo VIEW-AS ALERT-BOX QUESTION BUTTONS OK TITLE "InBank Information System" .
    END.
END.
 
Last edited by a moderator:

Cringer

ProgressTalk.com Moderator
Staff member
As has been stated previously, any user interaction within the scope of a transaction is bad. What happens if someone leaves this to run and goes home for the weekend? The message will appear and the transaction will be open until they come and click ok. All the while the BI will be growing, and you risk the whole system crashing.
 

RealHeavyDude

Well-Known Member
I can only second that. Your design of having message statements blocking the execution of the transaction until a button is clicked is a recipe for disaster - always was in a multi-user environment. As Cringer mentioned, making transactions larger than need be by waiting on user input bears the potential to blow the before image on the database and thus crashing the database so bad that you might even be forced to restore from your last backup. All the while your system being unavailable for all users.

You should redesign your logic to do whatever validation is necessary outside of the transaction block. For example find the records with no-lock and perform the validation. Only when the validation has been passed successfully, start a transaction and use find current exclusive-lock and update the record accordingly.

Heavy Regards, RealHeavyDude.
 

tamhas

ProgressTalk.com Sponsor
Done the COMPILE LISTING yet? You can also do it for the program that calls this one to see if there is a transaction active at the time of the call.

Other than that, I agree with the other advice you have been given. Sometimes, people think they need huge transactions out of some notion that it is a unit of business. Yes, ABL will nicely back the whole thing out for you if there is a problem, but 99.9% of the time it is possible to make the transaction size very small and provide a restart mechanism in the unlikely case that there is a failure.
 
Top