Question catch 915 error

[anandknr]

I would like to know if there is any way to catch the error: Lock table overflow, increase -L on server (915)

Below is an example I am using to create such an error condition. I know this will be a bad example, but all i need was to produce 915 error.

def buffer bacctg for acctg.
do transaction: /* main tran */
    for each acctg no-lock:
        do transaction: /* sub tran */
        find bacctg where recid(bacctg) = recid(acctg) exclusive-lock.
            bacctg.currency = "$".
    end.
    end.
end.

I tried with catch block but it is not actually catching this error message. So how will we handle this kind of an error?

 

[TheMadDBA]

I am not aware of any way to catch these kinds of errors. You are much better off doing two things....

1) Evaluate the size of your -L setting and see if you need to adjust it (might be at some horrible default). If the setting is accurate you can TEMPORARILY increase -L to provide time to do step 2..

2) Fix the transaction scope issues in your code.

That is pretty much all you can do.

 

[Cringer]

As MadDBA says, the second transaction keyword is completely useless in the context. Your issue is that you are locking every record in the acctg table, and hence blowing the lock table limit. If you really need that big a transaction scope, then option 1 of MadDBA's post is your only option. If you don't (and I suspect you probably don't) then don't have the main transaction keyword. You don't need it. You are forcing the scope of the transaction to be much bigger than is actually necessary.

 

[RealHeavyDude]

AFAIK the error 915 raises a stop condition in the ABL session which will not be catched by the structured error handling.

I always do something like this:

method private logical getFilesToUpload (
     input sourceFileName  as character ):
 
     define variable filesOkay  as logical  no-undo.
    get-files-to-upload-blk:
    do on error undo get-files-to-upload-blk, leave get-files-to-upload-blk
    on stop undo get-files-to-upload-blk, retry get-files-to-upload-blk:
    /* STOP Conditon trapped */
    if retry then do:
         assign filesOkay = false.
         errorMessage ( substitute ( 'Exception getting files to upload &1 [&2].', sourceFileName, stopCondition ) ) no-error.
         leave get-files-to-upload-blk.  
     end.
 
     /* Some stuff */

     /* We're good ... */
     assign filesOkay = true.
    /* Error handling */
    catch anyError as Progress.Lang.Error:
         assign filesOkay = false.
         errorMessage ( substitute ( 'Exception getting files to upload &1 [&2].', sourceFileName, anyError:GetMessage ( 1 ) ) ) no-error.  
         delete object anyError.
    end catch.
    end. /* get-files-to-upload-blk */
     return filesOkay.
end method. /* getFilesToUpload */

Heavy Regards, RealHeavyDude.

 

[TheMadDBA]

Hmmm interesting, I can't seem to get that working in V10 non classed based code. When I get some more free time I will try it a few more ways

Thanks

 

[RealHeavyDude]

I must admit that I did never try to catch the 915 error with this - this is just a generic way to recognize a stop conditon and I do use it also in procedures ( non OOABL code ). AFAIK it should also work in pre-OE10 code, but that I did not check that too.

For me it works in a way that I can gracefully bail out or handle the situation whenever the application hits a stop condition without reverting back to the first procedure in the session being re-run no matter what.

Heavy Regards, RealHeavyDude.

 

[TheMadDBA]

For the lock table overflow it seems to just keep kicking it back to the startup procedure no matter what I do. V10.2B, will try again on V11 later this week.

 

[TomBascom]

I believe that lock table overflow is an "uncatchable STOP".

 

[TheMadDBA]

That is what I thought as well. Kind of like memory violations and other nasty errors.

Always better to fix the core issue(s) anyways.

 

[RealHeavyDude]

One can learn something new every day - I wasn't aware that there are different kind of stop conditions. Some of which are trapped by the technique are run statements or function invocations that fail due to various reasons.

Heavy Regards, RealHeavyDude.