Skip to main content

Hi,

 

How can I overcome the error 500 when the following request is made:

 

DELETE https://twisodev01.acto.nl/indicium/iam/5414/someview(id=576001)

 

it gives a nice dialog in the screen that an error occurred due to this:

delete instead of trigger on the view executes a delete on the realtable

the delete trigger on the realtable has some condition:

    if exists (
               select 1
               from   deleted d
               where  d.is_locked = 1
              )
    begin
      exec dbo.tsf_send_message 'deletion_error', null, 1
      rollback tran
      return
    end
 

Now the magic starts:

It returns a 500 error on the request, which is a server error (is it?),

it registers an error in the indicium log (is it really?)

and the debugger in the windows gui shows a System.Net.WebException(why?).

 

What is the proper way to let indicium handle such a delete action where a trigger prohibits the delete and sends back the message to the user it cannot delete the record due to some constraints - in a way that we will not get a 500 error, but a more usefull 4xx error?

 

rgds Ricky

Hi Ricky,

The next version of Indicium (Universal) will react different, as it will throw a 422 status code error and shows the thrown message; in the tsf_send_message msg_id in your case.

The error will act similar to when a mandatory field has not been filled in upon saving. In Universal, the GUI will not go out of Edit mode anymore and the process flow will not directly continue with the red arrow.

This change is not implemented in Indicium (Basic)

So how can we properly (properly as in ‘As it was designed and meant to be coded’) code an application error or warning without resulting in a server error because that is what it is returning now. Now it clutters every single logfile there is - iis logfiles show 500’s, indicium logs show exceptions, the debugger is showing exceptions everything is throwing exceptions but we do not want it to be an exception and use that for traceability and monitoring.

 

The problem occurs when using @abort_ind = 1, that will result in a 500 error and these will be written to the Log. We are working hard on making the Windows GUI compatible with the Indicium (Universal).

For now, there will be a significant impact in converting the 500 errors to 422 errors for the Indicium Basic version as Mobile and the Windows GUI currently don't support this. It would also be a breaking change for all API's that are in Production.

 

I’ve fiddled with this concept yesterday and from my experience the @abort_ind = 1  doesn’t matter whether it is set to 0 or NULL it will return 500 to the client, will register an exception in the indicium log and the debugger will paste a System.Net.WebException in its content screen. This may be due to the fact that the transaction ended in the trigger. The batch has been aborted by the trigger within the execution - not the @abort_ind indicator.

Either way, when you’ve designed this way of application error handling through indicium, did you have another way of coding to handle such a delete action where a trigger prohibits the delete and sends back the message to the user it cannot delete the record due to some constraints?

The way Indicium (Basic) is handling this right now will not be changed and is fixed/changed in Indicium (Universal). The only thing to prevent this from happening is to make sure the transaction is not rolled back in the trigger since that causes the 500 error. (@abort_ind does not cause it, my mistake)

The best way to do prevent the 500 errors is using the Layout/Default procedures to your advantage by preventing the value(s) from being added/edited.

Thanks for the reply – Now I can rest assured that I haven’t missed anything.

Reply


Terms & ConditionsCookie settings