Scott Spendolini's Blog

Earlier today, I tweeted the following: After this morning, I don't think I will ever use the "v" function again. #orclapex I wanted to qualify what I meant by that, since sometimes you only see one side of the conversation on Twitter. Also, it's been a while since my last post, so this give me the opportunity to remedy that as well. The APEX "v" function works, and works quite well. For those who have not used it, the "v" function is an APEX-specific function that when you pass an APEX item to it, it will return the value of that item for a specific user session. What's cool about it is that it also works from named PL/SQL program units, as long as they were initiated from an APEX session. Thus, you can write a PL/SQL package that takes in few, if any parameters and still can refer to items that are set in the APEX session state via the "v" function: PROCEDURE foo IS l_customer_name VARCHAR2(255) := v('P1_CUSTOMER_NA

Not only is the title of this post a great song by one of my all time favorite bands (extra credit if you can name them w/out using Google) but is a question that some of you have been wondering... Most of my time the past few months has been spent on designing & developing sumnevaSERT - a security evaluation tool built in APEX for APEX. sumnevaSERT is the result of working with many customers over the past few years and realizing that they spent very little time reviewing the security of their APEX applications. They all had the same exact reason for neglecting them: no time.  sumnevaSERT makes it blindingly simple to evaluate an APEX application for a number of potential security flaws. It slices through the APEX metadata and produces a single score based on what it finds. You can then drill into any of the categories to see details and advice on how to fix what it finds.  Despite releasing it today, we've already got a list of exciting new features and enhancements