Hi @mark stewart the idea makes sense and we debated it today. However IR compute dialogs are designed for end users and we don't think it should offset that much code logic to the end user. We are closing this for now.

@vincent morneau Thanks for the feedback; that's a reasonable reason to avoid that.  But wouldn't it be interesting if there was a declarative option to enable turn on “expert” mode that would allow to_number!  But for now, I suppose I can just alter my query to do what I want.  I do remember wanting to use to_number in the IR Actions a few other times.  Useful for APEX applications used by programmers.

Will reconsider this one at our next internal meeting.

Problem:

There are no CAST or TO_NUMBER functions avail as part of the APEX functionality in the end user reporting screen of drop down menu options, see screenshots attached (and included below)

Why is this a Problem:

Forums and help searches on how to perform operations in which this needed (such as converting a date to a serial number, or converting text values to a number) nearly always reference using one of these two functions in order to do this. One is referenced as a “workaround” for the other. Without having either of these available, end users need to try and figure out (if they exist) “creative” solutions to this problem (which is time consuming).

Has this been a problem in the past?

1-As an example, last week, myself and 3 other people spent almost 5 hours trying to figure out a “creative” solution to this problem in order to create some reporting being asked of us by leadership as well as other users who are using the reports we maintain in order to plan their resources around infrastructure maintenance windows to perform customer impacting maintenance activities.

The 4 of us (at an average loaded Oracle IC labor rate of $140/hr yields: 4 IC4s at $140/hr x 5 hours of time spent = $2,800 of time spent. Had these functions been avail, the whole activity would have taken me less than 5 minutes to build the reports that were needed.

2-I alone have encountered this problem at least 5 times a year every year that I have worked here. Each time, it takes me 3-4 hours to try and figure out a solution (depending on the problem’s impact to the specific analysis I am being asked to do).

$140/hr x 4 hours = $560 of time spent each year x 5 times per year x 4 years = $11,200 of time spent by me on something that should have taken less than 5 minutes each time.

3- I am sure I am not the only one in this company who has encountered this problem (in fact, I found at least one other person who posted the same suggestion on the “Ideas” site) and that had to try and find some solution and spent a lot of cycles of time to do it. I cannot quantify this, but if it’s 500 users who encounter this problem once a year and they are IC3s or IC4s, that scenario alone would be:

500 users x 2 hours of time spent on workarounds x $125/hr = $125,000 per year.

When implemented, it would be wonderful if the release notes point to this Idea #! :)