Databases Reference
In-Depth Information
There may be many applications and many schemas in a workspace, but an application may only parse as one
(and only one) schema and can only be set during development. The following sections delve more deeply to give you
a full understanding of how these concepts relate.
APEX Users
To log in to an APEX workspace, you must have access to a valid APEX user. A number of different user roles are
available that dictate what you can do when you log in. The roles are as follows:
Instance Administrators
are special users who manage and maintain the overall APEX
instance. They can set instance level preferences and messages, create and manage
workspaces, monitor space utilization, and perform many other actions related to the
overall APEX installation. Instance Administrators are only able to log in to the special
INTERNAL workspace, which houses the APEX Admin Services application.
Workspace Administrators
are responsible for managing the details of a specific workspace
and can manage user accounts related to the workspace, monitor workspace activity, view
log files, override developer locks and settings, and so on. Although it isn't good practice, the
Workspace Administrator can also act as a Developer, creating and modifying applications.
Developers
are the users who create and edit the applications in the workspace. They
have access to the underlying tables in the schema(s) assigned to the workspace and may
create and modify database objects and stored PL/SQL units. Most people writing APEX
applications only need this level of access.
End Users
are only able to run applications in a workspace. They don't have direct access
to any of the underlying database objects, nor do they have access to any of the APEX
development modules. End users can't log directly into a workspace.
With the exception of the APEX Instance Administrator, APEX users are specific and unique to a workspace,
meaning you can have a user with the same name in multiple workspaces in a single APEX instance but each of these
users is unique. They can have their own passwords and settings and aren't linked together in any way.
When you're developing, you should get in the habit of logging in as a Developer as opposed to a Workspace
Administrator. Several safeguards are available to help keep developers from stepping on each other in a workspace.
If you log in as a Workspace Administrator, these safeguards are bypassed, and you may accidently interfere with
something someone else is working on. Although this isn't a problem in a workspace with only one developer, it's still
good to get into that habit.
â–
this topic uses the last three types of user. it assumes that apeX has been installed, a workspace has been
created, and you have been given the workspace administrator's login credentials. if you're using the hosted instance at
apex.oracle.com
,
then the username you were given when you signed up has the credentials of a workspace
administrator. if, however, you're using a local instance, either refer to the apeX documentation or get your instance
administrator to help you set up a workspace.
Note
Applications, Pages, Regions, and Items
Although a workspace starts off basically empty, you can have many applications that reside in a workspace. There
is no specific rule, but it's likely that all the applications in a workspace share something: they might all use the same
underlying database objects, target the same user community, or use the same method for authenticating users.
