Hi @markhawker76
The functionality you describing is a feature of dbms coverage which we don't use fully.
We are mainly using profiler and running dbms coverage as supplemental data.
We could think about running one or the other only as an option but the block coverage is not entirely accurate and have provided us with very interesting results.
I will investigate if using a pragmatyk Not feasible generate some data that we could use the exclude from current.
If not and lines are not recorded anywhere with some flag than I'm afraid its not possible.

Hi,

Thanks for replying quickly.

I looked into the information provided by the SYS.DBMS_CODE_COVERAGE package when reporting on a run. I can confirm that the information populated in DBMSPCC_BLOCKS appears to be correct when using the coverage compiler pragma. However I do see the issue, as there is no easy way of identifying executable code within that block (or series of blocks using 'NOT_FEASIBLE_[START|END]' arguments.

Many thanks,
Mark.

It would need to be investigated and developed as an enhancement.
I'm pretty sure it can be done but would require some decent testing and experimenting to make sure that it behaves correctly.

What vestion of DB are you using?

Hi,

I am using Oracle 21c EE with the latest patch set.

I searched and found an interesting article from Chris Saxon regarding code coverage using line numbers rather than “execution blocks”. He thought that code coverage by line numbers alone could give false positives — especially if you have the following code scenario:

IF func_a() OR func_b()
THEN …

Here there are two execution blocks that may or may not be executed due to short-circuit evaluation. Chris seemed to suggest a line-based coverage could falsely report coverage of “func_b()”, whereas the output of Oracle’s code coverage tools would yield a more accurate outcome.

I guess the hard part would be interpreting the data provided by the database into a format a developer can readily understand. If there were a way of representing both line numbers and execution blocks at the same time, perhaps the Oracle code coverage data (if accurate), would be the way to go.

Sign me up for helping to test if the utPLSQL team believe it is worth pursuing.

Kind regards,
Mark.

Hi @markhawker76
utPLSQL is combining plsql_profiler and dbms_plsql_code_coverage to provide line coverage with statement level coverage.

That way, if only part of the PL/SQL line was covered, it will be indicated in the report.

This provides best possible coverage information we can give.
So you can have line coverage and also statement coverage see documentation here and some example here

There is another discussion #1336 that also mentions option to use dbms_plsql_code_coverage as primary source of coverage information.

With DB version support bumped to 19c and above and implementation, this could also be done.