العمل علي ديزاينر 9i

[هانى سند]

السلام عليكم
operating system :windows Xp home edition with sp1
oracle developer suite ver : developer suite release 2 tipical installtion

عند محاولتي العمل علي برنامج oracle designer 9i
طلب مني اولا انشاء repository لهذا المستخدم
و عند عمل هذه ال repository
كله مشي كويس عدا انشاء الجزء الخاص بالwork erea
ثم بعد الانتهاء من انشاء repository
عند تشغيل طلع ايرور ان هذه الrepository ليس بها work erea
او ان الصلاحيات غير كافية
ما هي المشكلة
و ما هي الصلاحيات الواجب توافرها في اليوزر الذي تنشأ له ال repository
و ارجو من الاخوة الذين لديهم خبرة في الديزاينر ان يفيدونا عن الخطوات الواجب تنفيذها لتشغيله
ارجو الرد و الاهتمام
ومشكور اخواني

[kindghost]

Post Installation Phase
When the installation process has completed successfully,
you need to do the

following to make the repository ready for use: Enable Version Control, If Used
· Test Basic Repository Operations
· Create Subordinate Users
· Grant System Privileges to Users
· Grant Access Privileges to Users
· Start to Use the Repository Tools
Enable Version Control, If Used
If you will be using version control for repository objects, you must enable this
feature in the repository.
To enable version control, proceed as follows:
1. In the Repository Administration Utility, choose Options > Enable Version
Support.
2. Reply Yes to the "Do you wish to proceed?" message.
3. Click OK at the "Operation Complete" message.
4. Read the message about the use of the Repository Object Navigator and click
OK.
Test Basic Repository Operations
We recommend testing some of the basic repository operations before making the
repository available to other users.
To test the repository, proceed as follows:
1. If you have enabled version control, create a new default workarea:
a. Start the Repository Object Navigator by clicking Start and choosing
Programs > Oracle 9i Developer suite >Oracle 9i Configuration
Manager > Repository Object Navigator.
b. Use the same connection details that you used earlier for starting the
Repository Administration Utility.
c. Click OK to acknowledge the message about statistics.
d. At the Welcome screen, choose "Invoke Workarea Wizard" and click
OK.
e. Create a default workarea using the wizard.
To see the new workarea, you will need to open a new Navigator
window at the level of Private Workareas or above.
After creating a workarea follow the following steps to test that the repository is
working:
1. Press Start->Programs ->Oracle Developer Suite->Oracle 9i Designer-
>Oracle designer
2. Enter the user name repos_owner and the password repos_owner and in the
host string enter your database alias name.
3. Choose the name of your workarea.
4. Choose Entity Relation Ship Diagrammer in order to create a digram to test
that the repository has been successfully installed.
5. Press File->New.
6. In the Select Container Window press the push button to select a container.
7. In the select Object Window press the create folder button to create a new
container,rename the container as desired,click on the name of the container
then press ok.
8. Press ok.
9. Start placing entities into your entity relationship diagram.
Create Subordinate Users
If other users at your site are to have access to the repository, you will need to
create subordinate users. This is the term given to repository users other than the
repository owner. Any usernames you want to use for subordinate users must
already have been created as Oracle usernames via a CREATE USER statement in
SQL*Plus.
You create subordinate users from the Repository Administration Utility. Creating
subordinate users requires particular care to ensure that the users have the correct:
· system privileges (see the next section)
· repository privileges (e.g., whether they can create configurations or purge
object versions)
· access rights (see "Grant Access Rights to Users")
For full details of the procedure to create subordinate users, see the topic "Granting
repository access to an Oracle user" in the Repository Management help system.
Subordinate users must be assigned the CONNECT and RESOURCE database roles.
To do so, start SQL*Plus, connect as SYS and issue the following command for each
user:
grant connect, resource to username;
If you experience errors when trying to create subordinate users, see "Error
Messages When Creating Subordinate Users" in Appendix C.
Grant System Privileges to Users
Various system privileges are required by a repository owner and subordinate users
to perform certain repository operations. The following table lists various system
privileges, and indicates the operations for which the repository owner or
subordinate user will need them:
System privilege Repository owner Subordinate user
CREATE SESSION Connection Connection*
ALTER SESSION Diagnostics Diagnostics*
CREATE TABLE Installation, migration *
CREATE VIEW Installation *
CREATE SEQUENCE Installation *
CREATE PROCEDURE Installation *
CREATE TRIGGER Installation *
CREATE ANY SYNONYM Reconcile user
DROP ANY SYNONYM Reconcile user
CREATE PUBLIC SYNONYM Reconcile user
DROP PUBLIC SYNONYM Reconcile user
CREATE DATABASE LINK Migration *
CREATE ROLE Reconcile user
CREATE SYNONYM Migration *
CREATE ANY TABLE Registration
CREATE ANY VIEW Registration
CREATE ANY SNAPSHOT Registration
CREATE ANY SYNONYM Registration
CREATE ANY PROCEDURE Registration
CREATE ANY SEQUENCE Registration
CREATE ANY TRIGGER Registration
CREATE ANY INDEX Registration
CREATE ANY TYPE Registration
CREATE ANY CLUSTER Registration
SELECT ANY SEQUENCE Registration
SELECT ANY TABLE Registration
* these privileges are granted to subordinate users when they are assigned the
CONNECT and RESOURCE roles
Diagnostics privileges are required if, for example, you wish to enable SQL TRACE.
Registration privileges are required for registration of Oracle schemas in the
repository. See the online help for Repository Management.
Reconcile user privileges allow subordinate users to be enabled or disabled
(synonyms created or dropped) via the Reconcile button on the Maintain Users dialog
box of the Repository Administration Utility.
Some subordinate users may need additional privileges depending on which utilities
they will be running (e.g. Import/Export from the Repository Object Navigator). To
grant these, connect as SYS and enter any or all of the following as appropriate:
grant create table to subordinate_user;
grant create view to subordinate_user;
grant create procedure to subordinate_user;
grant create synonym to subordinate_user;
grant create sequence to subordinate_user;
grant select on dba_rollback_segs to subordinate_user;
grant select on dba_segments to subordinate_user;
Grant Access Rights to Users
The user who owns a workarea, container or configuration can grant access rights on
that item to other users, or revoke them from those users.
If you have created subordinate users, test the access rights mechanism as follows:
1. In the Repository Object Navigator, choose File > Access Rights > View
Access Rights.
2. Check the current access rights on the test workarea and container that you
created earlier.
3. Grant (at least) the Select access right on the workarea and container to one
of the subordinate users.
4. Change the connection to that user.
5. Check that the user can see the workarea (under Shared Workareas) and the
container.
6. Change the connection back to the repository owner and revoke the access
rights.
To grant an access right to all subordinate users (present or future), grant it to
PUBLIC.
Start to Use the Repository Tools
The installation of the new repository instance is now complete. Create any
workareas and containers required, grant the access rights to them and inform
subordinate users that they can now begin using the repository tools.
If you need help at any point while using a repository tool, choose Help > Help
Topics on the tool. If a dialog box is displayed, click its Help button.
Even within a single workarea, you may be able to see hundreds, even thousands, of
objects. Some way of organizing these objects is necessary. Oracle Repository
provides different types of containers in which to organize your objects.
Containers are similar to directories in a file system - they are simply a means of
organizing repository objects in a logical fashion. Note that the repository owner
must have assigned you the Containers repository privilege before you can create
containers.
There are two types of container, folders and application systems, either of which
can hold instances of any type of repository object. Folders are available even if you
install only the core repository (for example when using the repository as a source
control system). Application systems are available (as well as folders) if you install
Oracle Designer, for application development.
A special folder, the system folder, contains a number of predefined language types,
such as Java or Oracle Forms. You can use these when defining application modules,
for example. The system folder also contains a predefined preference set for use with
Form Generator, to optimize the look-and-feel of generated applications.
When you create a container, you are its owner. You can subsequently transfer
ownership to another user.
Any container can be placed under version control, as can any or all of the objects it
contains, but objects and their containers are versioned independently of each other.
A new version of a container is created when its owner either adds or removes
objects in it, or changes one or more of its properties (for example its name).
Appendix (A)
Version control is the process of maintaining multiple versions of software development
objects and is the most basic requirement for a software configuration management
system.
Both repository and non-repository objects can be version-controlled in the common
repository. About
The repository manages all repository objects, as well as file system files and directories.
This enables the tracking of changes to the organization of the source data, as well as
tracking the changes to the contents of individual files.
Versions are organized into a version tree structure with branches. Branches have userdefined
labels, typically chosen to indicate their role in the development process.
All object versions can be identified by system-generated version numbers or userdefined
version labels. You can choose the format used to identify object versions: either
the version label, or the branch label followed by the version number. How
Version history
Each object in the repository is held as a set of snapshots, called object versions, of its
state at certain points in time. The object versions are linked together by associations that
record how each object version evolved from its predecessors. This web of associations,
represented by the version tree, is called the version history of the object and can show
succession, branching and merging.
The version history associations also have a number of version control attributes,
including:
·
a unique version identifier
·
the identifier of the user who created the object
·
the date and time the object was created
·
the identifier of the user who changed the object
·
the date and time the object was changed
·
status of the object (for example checked out or checked in)
·
a comment (a descriptive reason for checking in or out)
Checkin and checkout
Version control starts when an object is checked in. Objects that are checked in are write
protected. The object must be checked out before it can be modified.
Only one version of an object can be included in a workarea and only one version of an
object is visible through the workarea view. However, the complete history of an object
and all the events that occurred to it can be viewed through tools provided by the
repository.
Any file or folder in your file system, as well as repository objects, can be the subject of
version control. You can copy files and folders into the repository and copy them back to
the file system. You can also synchronize your file system with the repository at any time
to ensure both are consistent. About
When checking an object in or out you can provide notes to briefly describe the reason
for the action.
Once the object is checked out a copy of the object is moved into your workarea. Your
workarea contains all the checked-out objects you are working with. When the object is
checked out, the workarea is refreshed so that the new object version appears in your
version resolved view and can be edited by you.
You can undo a check out but any changes you have made to the object are lost. The
system administrator has the privilege to cancel a checkout.
Branching
When checking in an object, you can decide if the changes are to be included in the
branch from where the object was checked out or if the changes are to be represented on
a new branch. Branch labels can provide some meaning to the development strand, for
example, as a set of changes related to bug fixes.
Many of the checkin options are available by default. For example the default action
could be to create a new branch, with a specified label. This default would apply to all
objects checked in from your workarea. This could enable all the changes made on a
given set of objects to be queried from the repository and used in release management or
quality assurance procedures.
Locking, comparing and merging
During the checkout operation, the object can be locked so that no other users can check
out a copy for editing. If you choose not to lock the object, there is the possibility that
when the time comes to check the object back in, another user may have made changes in
the interval. In these circumstances, and depending on who checks their version in again
first, the compare and merge tools have to be used to ascertain how to check the object
back in.
A compare operation compares two object versions and displays the differences and
details of the two object versions in the Compare window.
A merge operation combines changes that have occurred independently in two object
versions. A merge is typically required when development has taken place on a branch
and the changes need to be incorporated back onto the main line of development.
The merge operation takes two contributor object versions, compares them to a common
ancestor version, and uses internal rules to create a result version based on changes found
in all three versions. The differences and conflicts encountered by the merge algorithm
are displayed in the Merge window, enabling to view the selections and, if necessary, to
override those selections before the result is produced.[/align]

[mojtaba]

مضبوط اشتغل 100%