D
dbeavon
Guest
I'm looking for help with TT's (of the NO-UNDO variety). Does anyone have experience with a TT that raise an error twice for the same problem? I'm struggling with this. I found a KB article that describes the basics of the problem. It has workarounds but they are are truly strange and I'm hoping someone has a better approach that incorporates modern S.E.H. Progress KB - ERROR-STATUS:ERROR flag re-set by external procedure OUTPUT parameter In my programs I have S.E.H. in place and I catch the ProError related to the failure (unable to add a duplicate record): ** TT_Item already exists with "A123" 55951730 50843491 1. (132) For example, the following catch block will start executing after the unique constraint violation. /* ********************************************************************* */ /* Convert ProError's and AppError's */ /* ********************************************************************* */ CATCH v_ProError AS Progress.Lang.ProError: /* Empty dataset */ /* TEMP-TABLE TT_AllocatedItem:EMPTY-TEMP-TABLE(). */ /* !!!! RAISES ERROR AGAIN !!!! CANNOT PROCEED WITH ERROR HANDLING */ /* DATASET DS_ItemAllocation:EMPTY-DATASET(). */ /* Return the error */ p_ErrorAllocation = ParseStandardErrorMessage(v_ProError). RETURN. END CATCH. After I've caught and started handling the constraint violation, however, it will be raised again - either in the CATCH block or in the calling client program that shares the static TT and DS. Note that I've even tried to empty the temp table and dataset as part of my error handling. (currently that is commented out in my example above). But those attempts to empty the dataset will have the unintended effect of immediately raising the constraint violation again ... and prevent my CATCH block from completing!!! This is very strange behavior and it is the first time I've ever encountered it. The workaround in the KB suggests that there is no alternative than to make the TT an UNDO-able one. This seems extremely unhelpful since I do not want the overhead of the UNDO functionality on the TT. Is there any other approach? Shouldn't I be able to clear/reset the static data in the CATCH block without triggering yet another error???
Continue reading...
Continue reading...
