It might seem simple, but there's more to it than that. You're talking of providing a single string of characters and have something that parses that string to evaluate the expression contained within it and return the result of the expression. SQL has such a parser built into it if you use dynamic SQL to turn the string into a part of the SQL rather than an isolated string. You could also do dynamic PL/SQL code as well if you wanted:

Other than that, you'll have to write your own expression parser. If you've done a course on language syntax diagrams etc. you should find it easy enough to write on. I did one at university as part of our course (along with writing the graphical code editor, and compiler).

You can't do anything in PL/SQL without a PL/SQL environment. The vast majority of the PL/SQL environments out there run in an Oracle database. The remainder run Oracle Forms. Based on your first post, it doesn't sound like you're using Forms. Thus, the only other place that you could be using PL/SQL would be in a database. Which implies that you have to connect to the database.

Of course, nothing stops Oracle from releasing a standalone PL/SQL compiler/ interpreter that would run without a database. There just isn't a whole lot of demand for such a thing (though Brynn Llewellyn if you're reading, I'm totally in favor of it!). There are already any number of compilers and interpreters for different languages (Java/ C/ etc) that produce desktop applications.

It would simply be more efficient to do the calculation without a database call, if that were possible, which it apparently isn't.

Better to do:
A:= 21 + 3;
than
select 21 + 3 into A from dual;

What does a "database call" mean to you? Calling a PL/SQL function is a database call to me. Executing any operation in PL/SQL is a database call.

Of course, if you really, really wanted to, you could parse the string and do the computation without using SQL. It would be slower that making a single SQL call. You'd need to implement a bunch of logic that Oracle has already provided (you'd need to identify all the operators that you want to support, you'd need to code the order of operations rules, etc.). It's doable. But it's way more code and far less efficient than a simple EXECUTE IMMEDIATE.

I guess I'll just have to rewrite it using execute immediate with bind variables to stop the shared pool getting filled up with thousands of these statements, since none of you have a non-db solution.

Why are you going to be doing this thousands of times? That implies that you probably have an underlying data model problem that should be resolved.

970779 wrote:
I guess I'll just have to rewrite it using execute immediate with bind variables to stop the shared pool getting filled up with thousands of these statements, since none of you have a non-db solution.

The problem is that this:
EXECUTE IMMEDIATE 'SELECT '|| g_counters(idx).formula_text || ' FROM DUAL'
INTO g_counters(idx).new_adcv_val;
is in a loop, and the loop runs hundreds of times, so it creates new statements in the shared pool each time like this:
SELECT .25*1.5 + 43.35 FROM DUAL