Database Reference
In-Depth Information
There is obviously a lot more to an application than these simple building blocks.
But if you understand the basic hierarchy between these, you'll have a jumpstart when
it comes to building your first pages and a solid foundation when it's time to perform
the more intricate tasks.
Workspaces, Applications, and Schemas
Although the relationship between workspaces and applications is straightforward, it
becomes a bit more complex when you introduce the relationship with database schem-
as.
Figure 2-3
diagrams this relationship.
Figure 2-3.
How schemas relate to workspaces and applications
When a workspace is created, it's linked with at least one, and possibly many, un-
derlying database schemas. This provides access to database objects such as tables,
views, stored PL/SQL program units, and so on.
When an application is created, it's assigned a single “parse as” schema from the list
of schemas associated with the workspace. A
“parse as” schema
is the Oracle database
user in which all SQL queries and PL/SQL calls run by that application are executed.
So, if your application was defined with a “parse as” schema of
DOUG
, a query such as
select * from emp
would execute in the database as if it were written
select * from DOUG.emp
Because APEX applications are portable and may not necessarily be run in the same
schema they were developed in, it's not good practice to hard code the schema names
into your SQL or PL/SQL. Instead, APEX provides a replacement variable (one of
many you'll be introduced to throughout the course of this topic) for the “parse as”
schema. The
#OWNER#
replacement variable is substituted for the actual “parse as”
schema for the application at runtime. So the statement
