Limitations of the PL/SQL Wrap Utility

Limitations of the PL/SQL Wrap Utility

■Although wrapping a compilation unit helps to hide the algorithm and makes reverse-engineering hard, Oracle Corporation does not recommend it as a secure method for hiding passwords or table names.

■Because the source code is parsed by the PL/SQL compiler, not by SQL*Plus, you cannot include substitution variables using the SQL*Plus DEFINE notation inside the PL/SQL code. You can use substitution variables in other SQL statements that are not obfuscated.

■The wrap utility does not obfuscate the source code for triggers. To hide the workings of a trigger, you can write a one-line trigger that calls a wrapped procedure.

■Some, but not all, comments are removed in wrapped files.

■If your PL/SQL compilation units contain syntax errors, the wrap utility detects and reports them. The wrap utility does not detect semantic errors, such as tables or views that do not exist. Those errors are detected when you run the output file in SQL*Plus.

■The Wrap Utility is upward-compatible between Oracle releases, but is not downward-compatible. For example, you can load files processed by the V8.1.5 wrap utility into a V8.1.6 Oracle database, but you cannot load files processed by the V8.1.6 wrap utility into a V8.1.5 Oracle database.

Obfuscating Source Code with the PL/SQL Wrap Utility C-3

Limitations of the PL/SQL Wrap Utility

C-4 PL/SQL User's Guide and Reference

D

How PL/SQL Resolves Identifier Names

This appendix explains how PL/SQL resolves references to names in potentially ambiguous SQL and procedural statements.

This appendix contains these topics:

What Is Name Resolution?

During compilation, the PL/SQL compiler determines which objects are associated with each name in a PL/SQL subprogram. A name might refer to a local variable, a table, a package, a procedure, a schema, and so on. When a subprogram is recompiled, that association might change if objects have been created or deleted.

A declaration or definition in an inner scope can hide another in an outer scope. In the following example, the declaration of variable client hides the definition of datatype Client because PL/SQL names are not case sensitive:

BEGIN <<block1>> DECLARE

TYPE Client IS RECORD (...); TYPE Customer IS RECORD (...);

How PL/SQL Resolves Identifier Names D-1

Examples of Qualified Names and Dot Notation

END;

END;

You can still refer to datatype Client by qualifying the reference with block label block1.

In the following set of CREATE TYPE statements, the second statement generates an error. Creating an attribute named MANAGER hides the type named MANAGER, so the declaration of the second attribute does not work.

CREATE TYPE manager AS OBJECT (dept NUMBER);

/

CREATE TYPE person AS OBJECT (manager NUMBER, mgr manager);

/

Examples of Qualified Names and Dot Notation

During name resolution, the compiler can encounter various forms of references including simple unqualified names, dot-separated chains of identifiers, indexed components of a collection, and so on. For example:

CREATE PACKAGE pkg1 AS m NUMBER;

TYPE t1 IS RECORD (a NUMBER); v1 t1;

TYPE t2 IS TABLE OF t1 INDEX BY BINARY_INTEGER; v2 t2;

FUNCTION f1 (p1 NUMBER) RETURN t1; FUNCTION f2 (q1 NUMBER) RETURN t2;

END pkg1;

CREATE PACKAGE BODY pkg1 AS

FUNCTION f1 (p1 NUMBER) RETURN t1 IS

D-2 PL/SQL User's Guide and Reference