Avatar of Crimsonwingz
Crimsonwingz
 asked on

Is there a way to force a retry on error?

I am using an access database to handle scanning orders into folders as a PDF.  

The scan function works great.  It drops the image into a local file as a jpg, no problem.  
I open the jpg(s) in a report, which works.
I close the report, using acSaveYes, and this seems to be working correctly.
Where I run into issues (at least on the AccessRuntime side of things) is in this line

DoCmd.OutputTo acOutputReport, "rptScan", acFormatPDF, "C:\TempScan\Report.pdf"

In the Runtime environment, I frequently get a 2046 error, and it stops.

If we rerun the process (sometimes multiple times) it goes through with the exact same results.

I added in a statement to try to get around this, by having it loop back to the portion of the code above in the Handle_err

    Select Case Err.Number
        Case 2046
            GoTo StartPDFConversion:  {the line above}
    End Select

Rather than loop, its still coming up with the 2046 error.    

I am using RT2013 as I was seeing too many bugs with RT2016.  

Is there a better way to force a retry of the PDF outputting code so that it just retries again?

Any help would be greatly appreciated.

Jeff
Images and PhotosDatabasesPDFMicrosoft Access

Avatar of undefined
Last Comment
Mark Edwards

8/22/2022 - Mon
Jim Dettman (EE MVE)

You need a Resume instead of:


GoTo StartPDFConversion:  {the line above}


in the error handler.  You don't want a goto there as it leaves the error handler active.


 I would however add a counter and in the error handler, if it reaches a certain count, then resume with a line that exits the procedure.


Jim.

ASKER CERTIFIED SOLUTION
Arana (G.P.)

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
GET A PERSONALIZED SOLUTION
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.
Crimsonwingz

ASKER
Thanks both of you, I think thats the part I was missing.  I will look into putting the loop count in there as well.
Jim Dettman (EE MVE)

Just note that   Err.clear only clears the error object.


The error handler is still active.   You need to use a Resume statement.


Jim.

Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
Mark Edwards

Error 2046 usually has some kind of "action not available right now..." error description.  What is your error description?
Crimsonwingz

ASKER
I guess I am still struggling after I thought I had everything great :(  
The error 2046 is the "outputto is not available" message that comes up in so many questions.  I have my code in question below:

---

    DoCmd.OpenReport "rptScan", acViewReport, , , acHidden
    DoCmd.Close acReport, "rptScan", acSaveYes
    DoCmd.OutputTo acOutputReport, "rptScan", acFormatPDF, tmpFilePDF
   
Handle_Exit:
    Exit Function
   
Handle_Err:
    Select Case Err.Number
        Case 2046
            Err.Clear
            Resume StartPDFConversion:
    End Select

---

But the error is still popping up probably 1 in 5 times.   Am I handling the error incorrectly?  I recently added in the Err.Clear and Resume statements as suggest, and changed it from just RESUME to as shown (thats the header for the  start of the create PDF process).  Originally,  I was just calling a GoTo StartPDFConversion, which also failed.

The odd thing is I have a handler for there being nothing in the scanner, which sends the process back using RESUME, and that works fine (even without the Err.Clear).  

Yes, I do know I do not have a loop break set up in this yet, first I just want to get the err handler to retry.

If we manually restrart the process,  the scan will USUALLY go through the second time, so my hope is to have the system automatically retry on failure to save the extra staff effort.  Any suggestion?
Jim Dettman (EE MVE)

   Dim intErrorCnt as integer


   intErrorCnt = 0


    DoCmd.OpenReport "rptScan", acViewReport, , , acHidden

    DoCmd.Close acReport, "rptScan", acSaveYes

    DoCmd.OutputTo acOutputReport, "rptScan", acFormatPDF, tmpFilePDF

 

    FSO.MoveFile tmpFilePDF, strFilePDF

 

    strFilePDF = ""

   

Handle_Exit:

    Exit Function

   

Handle_Err:

    Select Case Err.Number

        Case 2046

            intErrorCnt = intErrorCnt + 1

            If intErrorCnt > 10 then

               Msgbox "Operation failed"

               Resume Handle_Exit

            Else

                Resume

             End If

        Case Else

           MsgBox "unexpected error"

           Resume Handle_Exit

    End Select


⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
Jim Dettman (EE MVE)

Not sure though what you want to set as a failure.


Jim.

Crimsonwingz

ASKER
When the outputto error occurs, it seems to be a temporary condition, so if that error pops, I want it to just cycle back to the beginning of that process and retry the outputto command until it is successful.
Jim Dettman (EE MVE)


 The way it is now with the resume, when a 2046 occurs, the statement that caused the error will re-try.  If that occurs more than 10 times, the procedure will exit.   


  Although it's not quite perfect the way it is.   The loop count on the 2046 error is against all the statements.  Not sure if that's possible or not (don't remember what 2046 is off-hand).


Jim.

All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck
Mark Edwards

You might try adding a "DoEvents" line before you enter the loop and in the loop to permit any pending actions to process before looping through again.  It may be that the output is trying to execute before other actions are complete.

A big question would be why it seems to be haphazard.