measures of type method return value only work within the context of a business transaction.
Standard measures return numbers, typically a response time which is for charting however return value measures will potentially produce a list of Strings. They can be used as split values for business transaction or filters for instance.
Did you add your measure to a BT?
You need to make sure that you have created a sensor for the method too and that you capture the argument. See here for more info: https://www.dynatrace.com/support/doc/appmon/admin...
the response time is slow because all the time is taken by the execution of the SQL statement.
So it is either a big table or it is returning a lot of data.
Going back your return value problem, what do you see when you right click and select details on the first node of your purepath? You should see the return value. If there isn't one, then your sensor is not recording the return value.
Make sure the "method return values will be recorded" tick box is selected.
I forgot to mention that you will have to restart your application to enable the change or perform a hot sensor placement (java only but right click on the agent on select hot sensor placement).
The accessor is required if the return value in not a primary data type (String, int, float etc.).
So if your function returns an int then you shouldn't have to do anything else. You are checking for the value 0 so I'm guessing it is an int.
If it isn't then this could be the problem. As long as there is an accessor you should be able to extract the value. For instance use something like getInValue(), obviously only if the method exists!
Again any change with sensor properties needs a Hot sensor placement/restart.
In this environment,it is not easy to just restart an application whenever we make changes on Dynatrace. Some of the applications Dynatrace monitors carry services of 5 OPCOs(Operation Countries) like this one. I find difficulties in requesting for Business and OPCO approvals to do this which may result into a decline of interest in this AppMon tool.
Therefore, i suggest that there should be a way to solve/ make these changes without a restart of an application.In java apps its nice because its just a matter of applying "Hot sensor replacement" but what of the .NET applications or others?
as far as I know you will get the same problem with all APM solutions relying on byte code instrumentation.
Typically these activities are carried out in a test environment and then applied to production once you are happy with the results. They are one off activities and therefore can be managed via the standard release cycle. Once sensors have been customised, they don't change anyway.