Test Case ::
1) efraer345 should be failed
2)2342er should be failed
3) #$%#$%sdfas34 should be failed
4)rahul bhandari should be pass
5) dfsd_` should be failed

BTW, your own previous article describes the very similar issue:

http://www.inside-oracle-apex.com/sql-embedded-into-plsql/

WBR, Yuri

your absolutely right. But my 12 years DBA’s background and experience tells me this issue is not an Oracle – it’s brain issue for developers. Just explain plan for every query incorporated into ApEx and a bit think – and much PL/SQL-SQL issues will be obvious.

I’ve checked execution plan for EVERY query I wrote for ApEx applications. Every query is testing on real volumes of data. Every front-end query is tuning for response time. Always.

Well-tuned queries = quick responses Web-applications.

This is the most important for hybrid PL/SQL-SQL code – quality and performance of all code.

“Divide et impera” – a good principe not only in politics, but also in programming.

In my example – separated computation of function wich ALWAYS must be determimistic ALWAYS gives incredible performance impact.

I’m not so sure if it was well-known by the average developer. And if you know something you always think that’s trivial and why haven’t I known this before.

Regards
Patrick

Just ALWAYS test all SQL and PL/SQL code for real data volumes before production and this ‘problem’ solves natively.

Anyway, when use TurDuckEn code of ApEx, PL/SQL is most uses language.

So, all trivial:

declare
v_x number;
v_res varchar2;
bedin
v_x := f(p_x);
select abc
into v_res
from t_table
where v_x between col1 and col2;
end;

works more better than

declare
v_res varchar2;
bedin
select abc
into v_res
from t_table
where f(p_x) between col1 and col2;
end;

Depending of table size – the difference in speed for both blocks can consists from 30 to 300 times.

No matter how good table indexes.

In second example the f() function calls every time in RANGE SCAN with index for query.

As I said – trivial.

Patrick, I think, Your target audithory not so stupid.

for a table with just a few rows it’s probably no problem, but there are always tables which have more rows in them and developers tend to use “design patterns” they have already used in the past. And in that case you have bad performance.

I think in such a case it’s better to already come up with a more performant solution, also for the small tables. To have a better “design pattern” for the future, where you don’t have to care anymore.

I think using the APEX feature “Application Attributes/Edit Security Attributes/Virtual Private Database” is a much better approach. Setting the context with DBMS_Session.set_context and using SYS_CONTEXT in the view definition is much better. I can not prove it, but I would assume that the SYS_CONTEXT is defined deterministic and just called once by the optimizer/query engine.

So in such a cases “v” is almost inevitable….but issue is the sameinevitable (http://forums.oracle.com/forums/post!reply.jspa?messageID=1558784)