Oracle Designer 6i Migration Guide
Part 5. Migrating generated Web/PLSQL applications to Oracle Designer 6i
|
Oracle Designer 6i Migration Guide |
This migration guide provides the information necessary for upgrading Web/PLSQL Applications that were designed and generated using earlier releases of Designer to Oracle Designer 6i.
The document discusses migration from the following earlier releases:
This document assumes that you have already installed Oracle Designer 6i and migrated your repository. (See instructions in Part 2 of this Migration Guide.) The document then explains steps you have to take so that you can:
Throughout the document, special mention is made of any migration issues known at the time of publication of this document.
There are a number of migration scenarios that are possible in bringing your Designer generated Web PL/SQL application forward into 6i.
In this scenario, you will regenerate all of your Web/PLSQL application from Designer 6i.
The goal of this scenario is to be able to generate your Web/PLSQL application out of Designer 6i and achieve the same results you got when generating out of your previous Designer release. No attempt is made to redesign your existing Web/PLSQL application to make use of new features available in Designer 6i.
This scenario has the following characteristics:
This scenario is appropriate when:
In this scenario, you will regenerate your entire Web/PLSQL application from Designer 6i. As you regenerate each Web/PLSQL module, you will make use of new features as appropriate.
The goal of this scenario is to take advantage of the new Web/PLSQL features available in Designer 6i. As with Scenario 1, you want to be able to generate your Web/PLSQL application and get the same user interface you got from your previous release of Designer. However, many new Web/PLSQL features have been added to Designer to make achieving the desired result easier. Many features that were difficult or impossible to generate with earlier releases of Designer are now supported. Thus, in one pass, you can eliminate post generation modifications and difficult constructs that were used only to work around limitations of earlier releases of Designer.
This scenario has the following characteristics:
This scenario is appropriate when:
This is the most complex scenario. In this scenario, you will migrate your application a little at a time, rather than all at once. You will begin by migrating your application to a 8i Database in a schema specific way, or create a database link and appropriate synonyms to your new database schema. You will then make the changes required to run the application generated from your previous release of Designer alongside Web/PLSQL applications generated from Designer 6i. Finally, over some arbitrarily long period of time, you will regenerate all of your modules out of Designer 6i.
The goal of this scenario is to allow you to regenerate your whole application, taking into account new features, but in such a way that you do not have to migrate your entire application in one go. This means you will be able to move the deployed application to the new tool stack before you have completely migrated every module. Thus, you can continue with bug fixes and new development in parallel with the continuing migration effort.
This scenario has the following characteristics:
This scenario is appropriate when:
The first 3 scenarios all eventually require you to regenerate your application. Any post-generation modifications will be lost. If you heavily modified your application post-generation, and the characteristics of Scenario 1 apply to your situation, you might consider only upgrading the database environment to 6i, and not upgrading to Oracle Designer 6i. This implies that all future maintenance has to be done manually in PL/SQL.
This migration guide does not cover 6i database migration. It will, however, discuss modifications that will allow you to continue to run your generated Web/PLSQL modules alongside other applications. For information on migrating to a 6i database, see Part 3 of this migration guide.
Note that, even though you may choose not to use Oracle Designer 6i for continued module generation, you may still use Oracle Designer 6i to maintain your database definitions. You may also choose to use the Software Configuration Management features of Oracle Designer 6i to manage your application source code. In that case you could bring in the previously generated and adapted packages as files in the repository and maintain these files for future enhancements and/or fixes. Note that in addition you can parse these packages - stored as files - for dependencies with the Dependency Manager for impact analysis.
For information on Software Configuration Management with Oracle Designer 6i, see the Oracle Technology Network at http://otn.oracle.com/products/repository.
Note that all scenarios result in an actual usage of Oracle 9i and Oracle Designer 6i and therefore you will be optimally serviced by Oracle Support on your Oracle tool stack, i.e., you do not need to implement costly workarounds, you can simply profit from regularly released patches.
Depending on which Designer release you are coming from, many Web/PLSQL features of Oracle Designer 6i may be new to you.
This chapter presents a brief overview of new features that are of particular interest when migrating a generated Web/PLSQL application. It is by no means an exhaustive list of all new features, and it does not try to explain each new feature in detail. Rather, it introduces the relevant features, and points you to where you can find more information in the Oracle Designer 6i online help. These new features may be referenced in the appropriate migration steps of the following chapters.
This chapter is organized by Designer release. You should begin reading at the section for your "from" Designer release, and then continue reading the sections for any later releases. For example, if you are migrating from Designer 1.3.2, you need to read all four sections below. If you are migrating from Designer 2.1.2, you may skip the section on Designer 1.3.2 and read the sections for Designer 2.1.2 and 6.0.
See Part 4, Chapter 3 of this migration guide for a general overview of these new features.
See Part 4, Chapter 3 of this migration guide for a general overview of these new features.
Oracle Designer 6i has added many new preferences. These preferences allow for greater flexibility in layout and provide for new methods of security.
Designer 1.3.2 introduced the concept of a Table API (TAPI) specifically for the WebServer Generator. The WebSever Generator utilized the TAPI to do any inserts, updates or deletes (and some selects) against a table. The TAPI auto-generated primary keys associated with sequences and audit columns, and allowed you to place your own specific code within the TAPI. The TAPI was not utilized with any other Designer generator. Beginning with Designer 2.1.2, the TAPIs became an integral part with other generators and were associated with table triggers, causing the TAPI code to be run during any insert, update or delete. Oracle Designer 6i has additional custom code placement options within the TAPI and auto-generates more functionality, including enforcing arcs, etc.
This section describes migrating from Designer 2.1.2 or 6.0. If you are already at 6i please skip this section.
Oracle Designer 6i departs from the use of lookup table usages to drive LOVs. LOVs can now be created as specific, reusable components and attached to an element. This provides for more flexibility and the ability to drive the LOV from a custom query. This is particularly helpful in the WebServer Generator in that it allows you to better define the look of Poplist type LOVs.
Prior to Designer 6i, the CG_REF_CODES table provided the only structured reusable table for multiple lookup types. This limited its usefulness to only lookups that fit within the column structure of CG_REF_CODES. The All Domains table feature extends this type of functionality to a table that can be custom designed to meet the needs of your application. Coupled with Reusable LOV components this becomes a very powerful new feature.
Reusable Modules allow you to define a module with base table usages, associated lookups, etc., and the re-use this definition in multiple generated modules. This provides enhanced standardization.
Oracle Designer 6i adds substantially to the preferences available for WebServer Generator modules. These preferences provide better control over layout and provide the ability to maintain “context” between modules. Because the web is stateless, information that may have been available in a previous module in the hierarchy may not be available in the current module. The Master Context section of the generator preferences provides a way to ensure context is available to subsequent modules. Please see the Oracle Designer 6i online help for more information on new preferences.
Oracle Designer 6i will generate multi-row screens to provide inserts, updates and deletes across multiple rows. This is determined at the module level.
Since Designer 6i release 4 you are able to generate more functional Oracle Portal portlets. Please see the Oracle Designer 6i documentation for more information on this feature.
This section will review issues that may arise with migrating from any previous release of Designer to Oracle Designer 6i. The following sections will deal with specifics of each release. For completeness, you may wish to read the sections regarding earlier releases than your own.
There are a number of actions you must take regardless of which migration scenario you choose.
This chapter is organized by Designer release. You should begin reading at the section for your "from" Designer release, and then continue reading the sections for any later releases. For example, if you are migrating from Designer 1.3.2, you need to read all sections below. If you are migrating from Designer 2.1.2, you may skip the section on Designer 1.3.2 and read the sections for Designer 2.1.2 and 6.0.
This section covers general migration issues when migrating from Designer Release 1.3.2, 2.1.x and 6.0.
In all cases perform a complete backup of your database and export of any affected schemas.
You will need to upgrade the associated libraries for the Web PL/SQL generator (wsgl, wsglm, cg$errors, etc.). Because you will be regenerating all components, there is no need to run the existing version of these packages alongside the new versions. In other scenarios you will be required to maintain both sets of packages.
WSGLM is often modified to provide messages tuned to your applications. Any changes to your existing WSGLM will need to be re-applied to the Oracle Designer 6i WSGLM package.
Occasionally changes might have been made to other library packages. Some of these changes may need to be reapplied, where others may not be needed due to new functionality within the product. For example, Designer 1.3.2 matched case on queries. The dynamic build_where_clause could be modified to overcome this. In Oracle Designer 6i there is an option to perform case insensitive queries (the default is case insensitive).
Depending upon the number of existing applications, you might have multiple copies of the WSGL libraries. By default, Oracle Designer 6i will install these libraries in one location (schema). If the schema has sufficient privileges, the installation will grant execute on these libraries to public and create public synonyms. In some cases you may prefer to have multiple copies of the libraries for use by different application systems. This can be done by installing the copies in separate schemas and pointing the application schemas to the appropriate library schema by use of private synonyms.
Designer 1.3.2 and 2.1.2/6.0 were typically run using either the Oracle Application Server PL/SQL cartridge or the WebDB listener. In both cases you had two methods of configuring the database login to run the generated PL/SQL components:
In Oracle Designer 6i, there are new security features that should be considered. In Scenario 1 we assume that you will utilize your existing access and security methods. The new features are discussed in Chapter 5 "Migrate, Regenerate All with Redesign".
Regardless of which scenario you approach, you will need a good understanding of your existing access and security mechanism. At a minimum you should determine your DAD settings and note any schemas and roles that are associated with securing your existing PL/SQL packages that comprise Web PL/SQL modules.
Designer 2.1.2/6.0 and 6i Web PL/SQL Generator utilizes a checksum routine to secure access to specific records. Regardless or the version of Designer, it is a good idea to change the function WSGL.CHECKSUM slightly so that your checksum is different than the default shipped. The easiest method is to change the mod number in the function, WSGL.CHECKSUM, from 4294967296 to some other large number. As you will be installing a new version of the libraries, specifically WSGL, previous changes to WSGL.CHECKSUM must be re-applied.
Designer 1.3.2, and 2.1.2/6.0 WebServer Generator applications were typically run with the OAS PL/SQL Cartridge or the WebDB Listener.
Although you can continue to use your existing Application Server, Oracle Designer 6i applications are likely to be run with Oracle 9i Application Server utilizing MODPLSQL. In general, the configuration of web pl/sql modules is very similar.
The DAD configuration information can be found in the file $ORACLE_HOME/Apache/modplsql/cfg/wdbsvr.app.
Beginning with Oracle 9iAS
1.0.2.2 the DAD password is encrypted within this file. The browser interface to configure this file is found
at
http://yourmachine:port/pls/admin_/gateway.htm where your machine is the machine name where Oracle 9iAS is installed.
After installing Oracle 9iAS, make a copy of the file $ORACLE_HOME/Apache/Apache/conf/httpd.conf
Modify this file and change the line
defaultType text/ascii
to
defaultType text/html"
The application server will then treat unknown content type as html. On rare occasions, with defaultType set to text/ascii, the html code generated by Designer WebServer Generator will be displayed as ascii text rather than an html page.
In this scenario, you will regenerate your entire application from Oracle Designer 6i, including all Web/PLSQL, libraries, menus and reports.
The goal of this scenario is to be able to generate your application out of Oracle Designer 6i and achieve the same results you got when generating out of your previous Designer release. No attempt is made to redesign your existing application to make use of new features available in Oracle Designer 6i.
This chapter is organized by Designer release. You should begin reading at the section for your "from" Designer release, and then continue reading the sections for any later releases. For example, if you are migrating from Designer 1.3.2, you need to read all sections below. If you are migrating from Designer 2.1.2, you may skip the section on Designer 1.3.2 and read the sections for Designer 2.1.2 and 6.0.
This chapter assumes that you have performed all the actions described in Chapter 3, General Migration Scenarios.
In most cases, migrating your 1.3.2 application to 6i will go smoothly. There are four specific areas that may cause difficulty: module level security (z_chk), utilizing calls to underlying values, return links and Table APIs.
Designer WebServer Generator modules utilize “Query, List, Detail.” A user is first presented with a Query Screen, then a list of items that match the criteria, and ultimately a detail screen that typically allows update. In many cases, the list screen will always be limited by a fixed where clause in the module. Releases of Designer 2.1.2 onwards implement a security check to ensure that users do not access the detail screen directly by changing the url. Designer utilizes a checksum value (Z_CHK) to enforce this. Every link on the list screen has Z_CHK=#####. The detail page checks to see that this checksum value is correct.
If you have defined your own method of calling a component based upon the URL, you will need to modify these calls to implement Z_CHK or turn off Z_CHK. You can turn off Z_CHK by setting the preference SECECS (Enforce URL Checksums) to No. Please see the Oracle Designer 6i online help for specifics on how to call wsgl.checksum to implement Z_CHK from your own code.
Note: It is a good idea to change the function WSGL.CHECKSUM slightly so that your checksum is different than the default shipped. The easiest method is to change the mod number in the package (4294967296) to some other large number.
In all releases of Designer you could reference values from routines placed in the user text area. This was not explicitly stated in release 1.3.2 and there were no APIs or standards set forth for doing so. Hence, calls made to these underlying values, by use of form_val.field_name, etc., will likely fail in the migrated application. Oracle Designer 6i specifies the use of these values. Please see the Oracle Designer 6i online help for more information on accessing these values.
Designer 2.1.2 and onward provide return links to allow the user to select a link to return to previous modules in the hierarchy. Because this was not available in earlier releases, the existing application may have coded return links in the user text area. You can turn off return links with the preference MODBRL (Build Return Hyperlinks).
Designer 1.3.2 required Table APIs (TAPIs) only for WebServer Generator applications. With Oracle Designer 6i the default is to have all transactions run the logic present within a TAPI. Hence, any code that is currently in the TAPIs will be run for all transactions regardless of the application. This is implemented through the use of table level triggers. You can disable this feature by deselecting the Generate Table API Triggers checkbox in the Generate Table API Definitions dialog box during generation. Other types of applications, however, may wish to make use of the TAPIs, hence, it is a better practice to move any code specific to Web PL/SQL modules out of the TAPIs and into the modules itself. Oracle Designer 6i has many new trigger points within the module to accept this code.
In most cases, migrating your 2.1.2/6.0 application to 6i will go smoothly. There are two specific areas that may cause difficulty: utilizing calls to underlying values, and Table APIs.
In all releases of Designer you could reference values from routines placed in the user text area. In many cases the format of calls or local access to these underlying values may have changed; calls made to these underlying values, by use of form_val.field_name, etc., will likely fail in the migrated application. Oracle Designer 6i specifies the use of these values. Please see the Oracle Designer 6i online help for more information about accessing these values.
Additionally, Oracle Designer 6i provides a preference for bringing master level information into detail blocks of a module. These preferences can be found in the Master Context area of the Web PL/SQL Generator preferences.
Designer 2.1.2/6.0 virtually insisted that you install triggers that implemented the TAPIs for all transactions. Oracle Designer 6i allows you to bypass generation of these triggers. In general it will not affect your Web PL/SQL applications if you do not generate these triggers. It may, however, allow the data to become inconsistent to what is expected from your application. Be sure to consider carefully the affect of not having the TAPIs fire for all transactions before deselecting the Table API Triggers checkbox in the Generate Table API Definitions dialog box during generation.
In this scenario, you will regenerate your entire application from Oracle Designer 6i, including all Web/PLSQL, libraries, menus and reports. As you regenerate each module, you will make use of new features as appropriate.
The goal of this scenario is to take advantage of the new features available in Oracle Designer 6i. As with Scenario 1, you want to be able to generate your application and get the same user interface you got from your previous release of Designer. However, many new features have been added to Designer to make achieving the desired result easier. Many features that were difficult or impossible to generate with earlier releases of Designer are now supported. Thus, in one pass, you can eliminate post generation modifications and difficult constructs that were used only to work around limitations of earlier releases of Designer.
This chapter assumes that you have already performed all the actions described in Chapter 3 "General Migration Issues" and that you have evaluated the steps in the previous chapter, "Scenario 1 Migrate, Regenerate All, No Redesign".
This chapter is organized by Designer release. You should begin reading at the section for your "from" Designer release, and then continue reading the sections for any later releases. For example, if you are migrating from Designer 1.3.2, you need to read all the sections below. If you are migrating from Designer 2.1.2, you may skip the section on Designer 1.3.2 and read the sections for Designer 2.1.2 and 6.0.
Please review Chapter 4 "Scenario 1: Migrate, Regenerate All, No Redesign", because this also applies to this section.
This section is an extension of the security section in Chapter 3 "General migration issues".
Designer 1.3.2 and 2.1.2/6.0 were typically run using either the Oracle Application Server PL/SQL cartridge or the WebDB listener. In both cases you had two methods of configuring the database login to run the generated PL/SQL components:
The first scenario, single user login, may have been extended to have multiple Database Access Descriptors (DADs) that pointed to specific database schemas.
The second scenario, database authentication, allowed the user to log in to the database as a specific database
user. Grants to specific PL/SQL components could then be made to a role, which would in turn be granted to
the database users.
In Oracle Designer 6i, there is a new security feature that should be considered. The preference SECPKG (Security
Package Name) allows you to specify a PL/SQL package that will determine the users' ability to utilize a component.
(Please see the Oracle Designer 6i online help for detail of SECPKG.) By utilizing SECPKG you can simplify
your deployment architecture to that shown below.
You can now grant execute on all PL/SQL components to PUBLIC. Your custom developed SECPKG package will return a true if the user is allowed to run the component, based upon your own criteria.
Note: You can continue to run the generated application exactly as you did before, making use of the default SECPKG which always returns true.
Extra: If you are utilizing WebServer Generator in the same database instance as Oracle Portal, you can utilize all of the Portal user and group features. You must run the Portal script PROVSYNS.SQL for the schema that contains your SECPKG package. You can then reference the Portal lightweight user name with a call to the Portal API wwctx_api.get_user. Additional Group and User API information is available within the Portal PDK (http://portalstudio.oracle.com).
In Scenario 1 we discussed four areas of concern: module level security (z_chk), utilizing calls to underlying values, return links and Table APIs. While these areas of concern remain, they also provide enhancements that may allow you to reduce the need for post-generation changes or custom code within the user text areas.
Oracle Designer Web PL/SQL Generator modules utilize “Query, List, Detail.” A user is first presented with a Query Screen, then a list of items that match the criteria, and ultimately a detail screen that typically allows update. In many cases, the list screen will always be limited by a fixed where clause in the module. Designer 2.1.2 and forward implement a security check to ensure that users do not access the detail screen directly by changing the URL. Designer utilizes a checksum value (Z_CHK) to enforce this. Every link on the list screen has Z_CHK=#####. The detail page checks to see that this checksum value is correct.
In the previous scenario we discussed how to turn off this feature to provide the same functionality as your existing application. In this scenario we will discuss how to make use of this feature.
In Designer 1.3.2 you may have “tricked” the generator into using a view instead of base table, thereby not allowing the user access to the underlying data in the table. With Z_CHK this trick is no longer necessary. By setting the generator preference SECECS (Enforce URL Checksums) to Yes the generated module will ensure that users only have access to the detail screen via the record list. (Please see Scenario 1 for more details.) Additionally, if you wish to access any detail records from other modules you will need to make use of the wsglm.checksum routine. Please see the Designer online help for more information regarding wsglm.checksum.
In Designer 1.3.2 navigation links were largely the responsibility of the developer. Designer 2.1.2 and forward provide links to components higher in the module hierarchy.
Table APIs were introduced in Designer 1.3.2 specifically for the Web PL/SQL generator. From 2.1.2 forward TAPIs are an integral part of the overall system. TAPIs have been extended to allow additional points of access to add custom code. TAPIs automatically generate code to provide denormalization and enforcement of constraints such as arcs, domain based keys (CG_REF_CODES and ALL_DOMAINS), etc.
Please review Scenario 1: Migrate, Regenerate All, No Redesign, because this also applies to this section.
Designer 2.1.2 left security largely up to the developer. Security was generally implemented by creating a schema that either owned the pl/sql packages that make up the Web generator module or had specific grants to those packages. Another option was to create roles with grants to pl/sql packages and ultimately grant those roles to users. In either case, the security was left to the DBA to developed and was limited to granting access to pl/sql via database grants.
Oracle Designer 6i provides a mechanism to define your own security policy. This policy is still implemented across the whole module, but it allows you to code the decision of access in any way you choose. Every procedure that is callable from a web browser first calls the package defined in the preference SECPKG, passing in the package name. The default SECPKG always returns true. By coding your own SECPKG routine you can base access on anything you like - it is not limited to database grants. Perhaps some modules should only be run after normal business hours, simply return false when called between 8 and 5. Additionally, when SECPKG returns false, nothing is returned to the browser. This allows you to code your own access error screen. You also have the ability to log invalid (or valid) attempts to run a module. Each call to a module component initiates a call to your security routine, giving an access point to log information regarding the module.
When the generator installs the module component, it will call a procedure, add_package_resp, in the package defined in the preference SECPKG, passing in the value of SECRES (Default Responsibilities) and all PLSQL Packages that make up the module. Your procedure, add_package_resp, can then insert these values into a table that will later be used to determine whether a user can run the package.
Designer Web PL/SQL components in version 1.3.2 were limited to insert, update and delete a single row at a time. Oracle Designer 6i now provides the ability to insert, update and delete multiple rows in a single html screen. Forms that were of type List/Form should be reviewed to determine if the new multi-row format will improve the user interface.
Oracle Designer 6i release 4 provides new functionality to integrate with Oracle Portal. Oracle Designer 6i will generate the wrappers required to present the screens as portlets within Oracle Portal. Because Oracle Portal and Designer Web PL/SQL generator modules both utilize Oracle 9i Application Server’s modplsql, great synergy can exist between these technologies.
If you are utilizing WebServer Generator in the same database instance as Oracle Portal, you can utilize all
of the Portal user and group features. You must run the Portal script PROVSYNS.SQL for the schema that contains
your SECPKG package. You can then reference the Portal lightweight user name with a call to the Portal API
wwctx_api.get_user. Additional Group and User API information is available within the
Portal PDK (http://portalstudio.oracle.com).
By utilizing the PDK you can determine what groups a user belongs to and map these groups to Designer Modules.
Oracle Portal provides great flexibility in navigation and presentation. By generating Portlet wrappers, you can place Designer modules on tabbed portal pages. Portal modules can be integrated on the same pages as Oracle Portal components such as menus, reports and charts.
This is the most complex scenario. In this scenario, you will migrate your application a little at a time, rather than all at once. You will begin by upgrading all of your Designer repository to an Oracle Designer 6i repository. You will then make the changes required to run Web/PLSQL generated from your previous release of Designer alongside Web/PLSQL generated from Oracle Designer 6i. Finally, over some arbitrarily long period of time, you will regenerate all of your modules out of Oracle Designer 6i.
The goal of this scenario is to allow you to regenerate your whole application, taking into account new features, but in such a way that you do not have to migrate your entire application in one go. This means you will be able to move the deployed application to the new tool stack before you have completely migrated every form. Thus, you can continue with bug fixes and new development in parallel with the continuing migration effort.
The basic method that allows you to run multiple versions at the same time is the same regardless of the versions. You should read all of chapters 3 and 4 prior to attempting this solution. You should back up any schemas that hold database objects, wsgl libraries and application components prior to attempting to reconfigure the system to allow multiple versions to run side by side.
The key to this method is segregating the different versions into their own schemas. Typically all of the database objects and the Web PL/SQL components might have resided in a single database schema.
In order to run your existing application alongside the new Oracle Designer 6i application components you will need to first migrate your existing application and associated Web PL/SQL generator libraries to a separate schema. In all cases you will need to grant select, insert, update, and delete on all database tables (including CG_REF_CODES) and sequences that are utilized by your modules. These grants must be granted directly, not via a role. Depending upon the version that you are migrating from, you may need to create synonyms to point to the database objects (Designer 6i introduced the ability to define the database object schema within the generator preferences. Earlier releases require synonyms.)
After moving all existing application components to a new schema as described above, the system should work precisely as it had previously.
Next, you can install the Oracle Designer 6i Web PL/SQL generator libraries. This can be done in the object owner schema or in a separate schema. For the purposes of this document we will assume that these libraries are in a separate schema.
Again, the original application should be tested at this point to ensure that it continues to run properly. The Table APIs should be installed next. In Oracle Designer 6i, TAPIs are intended to be usable by transactions other than Web PL/SQL modules. If you only intend to use TAPIs for Web modules, the TAPIs can be placed in the Schema in the diagram above. We will assume that you will utilize TAPIs throughout and hence will place the TAPIs in the object owner schema. In so doing, you must grant execute on the TAPIs to Schema.
You can now migrate individual components to Oracle Designer 6i and install them into Schema. Any logic placed in the TAPIs will be run for all transactions, including transactions from earlier Web PL/SQL modules.
Designer Web PL/SQL modules do not preface calls to the components with the schema name. Hence, depending upon your application server configuration, you will likely need to create public synonyms for all of the packages associated with your applications. This requires that your module names be unique across schemas.
While this configuration is the most complicated, it is based upon sound database techniques and can be accomplished.
Many specific scenarios will require a more complex scheme than that described above.
|
|
|
