Databases Reference
In-Depth Information
This will create the table without bringing any of the rows over. Then you'll want to copy only the
rows from the APEX_DEBUG_MESSAGES VIEW over to your new table, but to make this something that
can be run over and over, you'll only want to copy the rows that don't already exist in the table. Luckily
the PAGE_VIEW_ID column gives us something unique to compare against. The following SQL
statement will copy only the information that does not already exist in the table:
INSERT INTO MY DEBUG MESSAGES
SELECT *
FROM APEX DEBUG MESSAGES
WHERE PAGE VIEW ID NOT IN
(SELECT DISTINCT PAGE VIEW ID FROM MY DEBUG MESSAGES);
To automate this process, you can include the above SQL statement into a stored procedure and set
it up to run regularly as a database-scheduled job. And to make sure that you are always looking at the
latest information, you can create a view that joins the data in your table with the data in the APEX view,
as follows:
CREATE OR REPLACE VIEW MY DEBUG MESSAGES V
AS
SELECT *
FROM my debug messages
UNION
SELECT *
FROM APEX DEBUG MESSAGES
WHERE page view id NOT IN
(SELECT DISTINCT page view id FROM my debug messages);
Now you have everything you need to duplicate the screens and reports that APEX provides you as
part of the debugging interface. In fact, you can actually replicate it 100 percent by simply examining the
code behind the APEX pages.
Note
If you're not already aware, you can load the APEX core applications up into a workspace and examine
the code and SQL statements that make them tick. Most of the core code of APEX is held in the wrapped packages
in the APEX_040000 schema, but most of the APEX magic is there for you to examine.
Examining the Debug Data
Now that we know where the Debug data is kept, let's have a look at exactly what is being kept. Table 6-1
lists each column and gives a description of the data it contains.
