[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Double jeopardy when a NO-UNDO temp table violates a uniqueness constraint

Status
Not open for further replies.
S

ske

Guest
> The fact that I can't seem to avoid the raising of the error is the problem. If you assign another unique value to the field with the constraint after the error was first raised, then it will stop raising any more errors... (Or delete the record, as others have said.) If you feel uncomfortable deleting or changing the record blindly when handling the error in the calling program, you could guard it with e.g IF NEW . The record remains NEW longer than usual, since it wasn't inserted into the database due to the error. (At least it does in other very similar cases that I tried.) If it is not NEW, some other error must have occurred. I don't understand, though, why you would not like to handle the error (delete the record) already inside the called program where the error occurred. Doing it any other way breaks the separation of concerns between the programs, as you mentioned. I would take that as a good reason for handling it there. And afterwards you can rethrow the error, if you still want to signal the caller about it too or go on to some more general error handling. Isn't that what rethrowing errors is good for? Doing whatever cleaning up that really needs to be done locally. I would put the (inner) handling as close as possible to the assignment of the field with the constraint where this particular error is expected to occur, and then that would also avoid unrelated errors from other statements landing in the same catch. Or just add a check that your field value is unique before assigning the value to the record, if you don't want to trigger error handling. Since it is a temp-table, there should be no concurrency-issues with doing that. Or enable UNDO for the temp-table, if you really want the system to get rid of the failing record automatically for you. What is the system supposed to do with the illegal record you created, if it is not allowed to UNDO it? It will stick around until you delete it or change the value. Letting EMPTY TEMP-TABLE ignore the illegal record in the buffer sound like a good idea, though. Or maybe failed records should stop trying to insert themselves into the database again and again? Don't try again until some new assignment is done or an explicit RELEASE statement is encountered, and otherwise just let it be discarded when it goes out of scope. (Another option might even be to throw away the failing record immediately when raising the error, even without UNDO, just letting the buffer become empty (NOT AVAILABLE). But I guess that would be too aggressive, given existing ABL programs that would not expect that, or that want to see what was in the buffer when handling the error.)

Continue reading...
 
Status
Not open for further replies.
Top