How to Installing the Patch Set for ORACLE DB

A).Installing the Patch Set interactively

1.Log on as a member of the Administrators group to the computer on which to
install Oracle components.
If you are installing on a Primary Domain Controller (PDC) or
a Backup Domain Controller (BDC), log on as a member of the Domain Administrators group.
2.Start Oracle Universal Installer release 10.1.0.4 located in the unzipped area of the patch
set. For example, Oracle_patch\setup.exe.
3.On the Welcome screen, click Next.
4.On the Specify File Locations screen, click Browse next to the Path field in the Source section.
5.Select the products.xml file from the stage directory where you unpacked the patch set files,
then click Next. For example:
Oracle_patch\stage\products.xml
6.In the Name field in the Destination section, select the name of the Oracle home that you want to update from the drop down list, then click Next.
7.If you are installing the patch set on an RAC cluster, click Next when the Selected Nodes screen appears.
8.On the Summary screen, click Install.
This screen lists all of the patches available for installation.
9.On the End of Installation screen, click Exit, then click Yes to exit Oracle Universal Installer.

B).Installing the Patch Set Noninteractively

1.Log on as a member of the Administrators group to the computer on which to install Oracle
components.
2.Copy the response file template provided in the response directory where you unpacked the
patch set archive file.
3.Edit the values for all fields labeled as "Value Required">as described by the comments
and examples in the template.
4.Enter a command similar to the following to start Oracle Universal Installer in noninteractive
mode. If Oracle Universal Installer is located in Oracle_patch\setup.exe, then pass the full
path of the response file template you have edited locally as the last argument:
C:\Oracle_patch> setup.exe -silent -responseFile response_file_path
where Oracle_patch is the location of the patch set you downloaded and
response_file_path is the full path of the locally edited response file.

Read-only methods (PRAGMA methods)

Methods can be divided into two types:

• Normal methods

These methods is methods that manipulates data in the database.

• Read-only methods (PRAGMA methods)

These methods are methods that are connected to a PRAGMA that guarantees that the method never writes to the database.
This means that PRAGMA methods always are read-only. All PRAGMA methods is automatically granted when the package is granted.
There are a few methods that are considered to be PRAGMA methods by naming standard in IFS Applications (even if they are not connected to a PRAGMA in the code).
These methods are:
ENUMERATE
EXIST
EXIST_DB
LOCK__
LANGUAGE_REFRESHED
INIT
FINITE_STATE_DECODE__
ENUMERATE_STATES__
FINITE_STATE_EVENTS__
ENUMERATE_EVENTS__
Views

How to use Crystal Report for IFS Application

step by step as below:

1)Report Design thru Seagate CryStal Reports (xxx.rpt)

2)To add the xxx.rpt in Quick Report
thru IFS/Admin/Fnd1 AdMin/Quick Report

3)To Find Report id thru IFS/Admin -> Installation-> SQL Query tool
by using sql as belos:
select quick_report_id,description from quick_report;
(let quick_report_id is 99 as a example)

4)To add quick_report_id to Customer-Menu
Thru IFS/Admin - Fnd1 Admin\CustomMenu\CustomMenu-Detail

ActionType: SAL Code
Windows :enter the window identity – like :tbwPurchaseOrderLinePart
Parameter :InfoServer.QuickReportStart(SalNumberToStrX(99,0)//'@')
//please note :the number 99 is quick_report_id

5)To activate In IFS Application & enabled Custom Menus

the form ‘Properties’ – Window tab pop-up details
have enabled Custom Menus (tick the box).

History of IFS Foundation1 (2005-2006)

2005

The Edge project continued during 2005. The work with client technologies for the "next level user productivity" took on more concrete forms. The platform was used for the OEE and system administration modules was given the name IFS Rich Web Client. Implemented with .Net technology it offers the possibility to build rich and innovative user interfaces, whilst at the same time providing a fully web based, zero install, deployment solution. In the later half of the year research was initiated to see how this new client platform could be applied to larger areas of IFS Applications.

Work on the system administration modules resulted in the creation of IFS Solution Manager - a new easy-to-use administration and configuration tool for IFS Applications. One important aspect of IFS Solution Manager was the ability to perform admin tasks as any normal user, with individually grantable tasks. Enabling clear segregation of administrative duties this would make it easier to comply with SOX and other regulatory requirements.

During the year a lot of work was also done on the IFS Web Client. In particular the web client got the same possibilities to configure the screen layout as the windows client had received the year before. Combined with a new implementation of user profiles that was shared across all clients this turned out to be very powerful.

Another key theme effecting all parts of F1 development during the year was security. Following the tag line "secure by design and secure by default" frameworks were reviewed, new security concepts added, and configurations changed. Important improvements included the move to JAAS (Java Authentication and Auhtorization System) for middle-tier authentications, the introduction of security privileges, and establishing a more secure default configuration.


2006

April 2006 saw the release of IFS Applications 7 - the result of the Edge project.

The next project - Sparx - has just started. Under that project Foundation1 will continue to be developed with both short and long term goals in mind. A lot of improvements are planned for service packs on IFS Applications 7.

At the same time work development of some key features for IFS Applications 9 has arleady started.

History of IFS Foundation1 (2004)

2004

In 2004 IFS started the Edge project which was to be a longer-than-usual development project for the next core version of IFS Applications. Where this project was largely about vertical industry functionality, a key theme for Foundation1 was to be usability and user productivity.

The goal was to achieve a leap forward and deliver a level of user productivity never before seen in business applications. To this end IFS started serious research and prototyping into everything from user centric design methodologies to new ways of visualizing information.
The result was a series of prototypes demonstrating new concepts. Taking this one step further an application project called "1st Solution" was started.
The mission for this project was to put the new innovations and techniques into use in a real application. After a first approach to build a complete business solution the scope was changed to deliver a new version of the Overall Equipment Effectiveness (OEE) and System Administration modules.
In parallel with the work devoted to usability research and development of new client technologies, a lot of time was also spent defining the second generation of the services layer in IFS Service Oriented Component Architecture.
In particular the logical model was being extended to provide a closer alignment with BPEL concepts, as it was becoming increasingly clear that BPEL would become the de-facto standard to describe processes oriented software components. Further enhancements were also made to the storage model to enable more flexible and efficient reuse of and integration with the application core layer. IFS Developer Studio saw significant improvements, in particular to make the RAD process more productive as well as improving the support for development teams.

Because of the longer than usual development cycle, a fair amount of time was also dedicated to improving IFS Applications 2004. Work on supporting high availability, scalability, and secure deployments continued with new product certifications and support for more advanced deployment topologies. Significant updates were also made to the two newest components in Foundation1, namely IFS Report Designer and IFS Mobile Client. These updates incorporated feedback and improvement suggestions from early adopters.

The highlight of improvements on IFS Applications 2004 was however service pack three, which in the fourth quarter brought new possibilities for configuring the screen layout.
Now it was possible to move and hide fields, as well as changing the tab order and marking certain fields as mandatory or read only. With the possibility to adjust screen layout to specific user groups and the task at hand, user productivity could be increased and training costs lowered.
For the existing customer base this functionality was the first clear result from IFS' increased investment into usability.

History of IFS Foundation1 (2003)

2003

The Chhiri project progressed as planned and in May the migration work and the RAD tools were completed. In the mean time the hype around web services had led to discussions in the software industry, highlighting the benefits of Service Oriented Architectures (SOA) when it comes to ease of integration and application extension.

This, combined with a desire from IFS to provide easier-to-use and well documented interfaces for partners and customers alike, led to the decision to incorporate the architecture (which was service oriented), techniques and tools originating from the Ti22 project (and now moved to J2EE by the Chhiri project) into the core Foundation1 architecture. In practice this meant splitting the business logic tier into two sub tiers - one application core tier containing the existing business logic, and one services layer, where service-oriented interfaces to the business logic are placed. This change not only allowed restructuring, consolidation, and simplification of the entire Foundation1 platform - it also created the architecture platform on which IFS could initiate key development investments for the coming years.
The extension of the architecture with a services layer, and the incorporation of a new RAD tool for that layer, was such a big step forward that it deserved giving the architecture a new name. And so the Open Layered Architecture (OLA) from 1995 was now officially superseded by IFS Service Oriented Component Architecture (SOCA).

The Handshake project working on a platform for mobile clients continued throughout the year. The framework itself, as well as the mobile applications, were developed completely according to the SOCA architecture. In October the first beta release was ready.


Following IFS principle of continuously updating and replacing technologies, 2003 also became the year when one of the oldest parts of Foundation1 would see its first big overhaul. Under the umbrella of the "Bayonet" project a new architecture for operational reporting was developed. Existing reports would be complemented to produce XML data.
A new WYSIWYG report layout tool - IFS Report Designer - was developed.
The new solution was based entirely on open standards, where IFS Report Designer created an XML style sheet that would transform the XML report data into a XSL/FO (Formatting Object) file, which was then rendered into PDF for viewing/printing. As all new development of Foundation1, the new solution was built according to SOCA and made good use of the services layer.

In the second half of the year a lot of work went into consolidating Foundation1 in order to lower the cost of deploying and operating Foundation1 based applications. Things like installation, configuration, authentication, were homogenized throughout the different parts of the platform, and bits were "merged" to reduce the number of parts in the platform. Combined with the move to a standard J2EE middleware this resulted in a Foundation1 platform that was significantly easier to understand, install, and operate.

In November Foundation1 2004 was released together with IFS Applications 2004. The entire web and middle tiers were now fully on the J2EE architecture, with support for all leading application servers. The consolidation meant that there was now a single component where all runtime and development tools for the services layer of SOCA were collected - "Extended Server". The "original" Foundation1 component with runtime, tools, and services for the application core was renamed "IFS Base Server". All the new parts (services, mobile clients, XML reports) now used the common RAD environment created by the Chhiri project. Because of it's central part in current and future versions of Foundation1 this environment was given the ambitious name of "IFS Developer Studio".

History of IFS Foundation1 (2002)

2002

IFS Applications 2002-2 was released 19 April - and with that also Foundation1 2002-2 which includes most of the functionality developed by the Ti22 project during the previous years. This includes the CORBA middleware, BizAPI development framework, new Connect integration framework, and the client access technology.
The Web Kit and IFS Applications web interface had been moved to the J2EE platform and IFS Applications 2002-2 no longer used ASP technology.
The new, easier way to integrate using XML BizAPI interfaces and IFS Connect to publish these as web services was of the main news in IFS Applications 2002-2.

2002 was also the year when the consolidation of application server technologies really started to happen. Out of a sea of quasi-compatible CORBA and Java application servers, came the J2EE 1.3 specification and a set of J2EE application servers that were mature, compatible, and fast enough to be considered for a wider use with business applications. At the same time Microsoft was really beating the drum for .Net and the .Net Framework. It became clear that it was only a matter of time before application servers became commodity. This was confirmed when some vendors started to give their products away for free, and with the availability of high-quality open source J2EE servers.

Realizing that sooner or later it would not be economically sensible to use anything other than standard J2EE also in the middle tier, and having experienced first hand the challenges of working with CORBA, IFS decided to do the change sooner rather than later. The Chhiri project was initiated to phase out CORBA in favor of J2EE. IFS tradition of encapsulating infrastructure in Foundation1 and thus hiding it from the application meant that it was only the Foundation1 frameworks that needed to be changed.

As IFS Applications 2002/3 and the new service based IFS Connect gained momentum, the need for a more productive and better integrated development environment to build services and other Java artifacts became apparent. Consequently the Chhiri project was given the additional directive to produce a highly productive RAD development environment.

Anticipating a rapid increase in the use of mobile devices (PDA:s, mobile phones) in a couple of years time, IFS had early in the year started an effort to extend the architecture, frameworks and tools of Foundation1 to cover volume production of mobile clients (user interfaces) for functionality in IFS Applications. This would be known as project "Handshake". The project set out to solve two key issues facing mobile business applications at the time.

The first was to avoid device lock-in by building a platform that allowed the mobile applications to run on multiple current and future devices.
The second was to create a solution that would work "online when available".

The first task for the project was to survey the market for mobile infrastructure (micro databases and the likes) to use. In the end IBM technologies were chosen - the J9 virtual machine, DB2e database, and MQe message manager. And creation of the frameworks could start.

History of IFS Foundation1 (2001)

2001

During the spring of 2001 the move of the Web Kit into a pure Java architecture,
using Java Server Pages (JSP) and Java Servlets instead of ASP for page layout, and CORBA instead of COM for backend communication was completed.
The project to migrate the actual web pages in IFS Applications ran in parallel and was completed during the fall. A special tool was developed to automate migration of the thousands of ASP+JScript web pages in IFS Applications to JSP+Java.
This means that for IFS Applications 2002 - to be released spring 2002 - the web interface can be used with any web server (Apache, IIS, etc.) and any operating system.
This migration was achieved while heavily extending the IFS Applications web interface.
IFS Connect saw its biggest development ever. The framework and most of the adaptors were moved to the new middleware. New adaptors equaling the functionality of IFS Event Server were added. The Event Server introduced in 1996 was now completely superseded by IFS Connect and no longer needed. The reborn IFS Connect framework was given built-in support for SOAP over Http, XML Schemas, and out-of-the-box integration to MS BizTalk Server and IBM WebSphere MQ.

The Ti22 project continued to run throughout the year working mainly on the new middleware, the new connect framework and supporting services.
The concept of BizAPIs was launched as a name for XML integration interfaces developed directly under the CORBA architecture. A Java framework for development of BizAPIs was produced, and a project to provide an initial set of BizAPIs for the coming IFS Applications 2002 release was initiated. The possibility of using the CORBA middleware for client access from custom clients was explored and access providers for both Java and COM were developed.

History of IFS Foundation1 (2000)

2000

During 2000, IFS significantly increased its R&D efforts to produce IFS Applications 2001. Foundation1 was no exception and a number of major improvements were made. The Windows client was modernized to Office 2000 look-n-feel. IFS Connect got new adaptors for OPC (OLE for Process Control), WAP phones, barcode readers, IBM Mobile Connect (Handheld solutions), and more.

The average size of IFS customers had grown significantly making multi-site installations more the rule than the exception. To make such installations easier, new functionality for configurable replication of any business object was added.

The Web Kit continued to be developed. For a while, the Web Kit team had been looking at different types of web portals that were becoming so frequent on the web. Ideas of a user interface based on a portal metaphor rather than Windows applications had been growing. The serious work began early in the year, leading to IFS' 3rd generation web interfaces with the IFS Personal Portal as a unifying personalized view into IFS Applications and other information sources alike. The look-n-feel and behavior of the web interface had changed completely. The difference was amazing, and the new interface was so much easier to use.

The Web Kit was also separated from the IFS Foundation1 component and released on its own. Similarly, IFS Connect was split into two components with a separate component containing the adapters. The Foundation1 platform now consisted of IFS Foundation1 3.0, IFS Web Kit 3.0, IFS Connect, and IFS Connect Adapters.

IFS Applications 2001, launched at the end of the year, included over 200 portlets for the personal portal, B2B and B2E web solutions for nearly all components of IFS Applications.
The Ti22 project, started at the end of 1999, continued.

A CORBA middleware had now been chosen and frameworks for server and web development were being built. The implementation architecture chosen was completely service oriented, with native support for XML in all areas. Because of the death of dot coms, the focus of the project shifted from B2C web sites towards B2B web, business process and application integration.

At the end of the year the decision was made to move IFS Connect and IFS Web Kit onto the new middleware. Since almost all the code in IFS Connect and IFS Web Kit is Java, this was not an overwhelming task.

History of IFS Foundation1 (1998-1999)

1998

At the beginning of the year, focus turned to usability, easy data retrieval, and ad hoc reporting. Features such as quick reports and single-click export to Excel were introduced. Support for handling EDI messages was added. A lot of work was also put into fixing bugs, memory leaks, and just making the whole environment more stable. This led to version 2.1 of Foundation1 on which IFS Applications 99 was released in the fall. IFS Applications 99 had a lot of new functionality and became a huge success. There is still a decent customer install base for IFS Applications 99.

The Web Kit continued to be developed and was integrated into the life cycle support tools of Foundation1. Web interfaces were released for selected components of IFS Applications 99 towards the end of the year. Most popular with customers were the web interfaces for time & attendance and work order handling.

In the area of general trends, business applications started to become more and more integrated. There was integration with other applications, new types of clients, and various devices such as mobile telephones, bar code readers, and radio terminals. To stem an emerging flood of custom-made solutions in IFS Applications, a project to develop an extensible integration framework was started. The framework should use XML as the native data format and have pluggable adaptors for other protocols and standards. Just as for the Web Kit, the implementation was done in Java and executed as COM objects under MS Windows and MTS.

1999

The integration framework started the previous year was completed and released as IFS Connect. IFS Connect was released as a separate component. The Foundation1 platform now consisted of two components: IFS Foundation1, containing the client-server development environment and life cycle support, and IFS Connect which was the integration framework.

Experiences from the first customer installations of web user interfaces resulted in a major overhaul of the Web Kit internal structure and the HTML output created. This work led to the second generation of IFS web interfaces with significant performance improvements and a lot more browser-side functionality. IFS now started to package two types of web solutions, B2E (Business-to-Employee) and B2B (Business-to-Business). The B2E interface was essentially an alternative full user interface for IFS Applications, while the B2B interface was specifically developed for use by external partners such as customers and suppliers. The Web Kit also started to become used by .com startups to build market places and other solutions with IFS Applications as the back end.

IFS Applications 2000 was released in the fall, again with lots of new functionality and entire new solutions. More and more customers started to make use of the new web interfaces and integration capabilities provided through IFS Connect.

1999 was also the year of .com startups, and IFS got involved with quite a few, particularly in the Nordic market. Another significant change was that ERP applications, including IFS Applications, broadened their scope to cover new areas such as CRM, eBusiness solutions (anything from back end application integration to consumer web shopping). It became clear that in the future IFS would be building application components with more varying characteristics than had been the case. While the architecture used by Foundation1, with business logic running inside the database server, was (and still is) ideal for database-intensive applications, new capabilities would be needed by some of the new components in future versions of IFS Applications. Promoting a freedom of choice strategy, IFS also wasn't satisfied that both the Web Kit and the Connect framework relied on Microsoft COM middleware and thus would only run on Windows.

To meet future requirements, the Foundation1 group started project Ti22 at the end of the year. The mission of the project was to identify a platform-independent middleware, an implementation architecture for high-performance application servers, and new innovative technologies for building high-end B2C web solutions.

History of IFS Foundation1 (1996-1997)

1996

Foundation1 was now a complete application development platform.
Rational Rose had been introduced as the design tool,
and IFS/Design helped transform the Booch object models to implementation code.
The Build and Deploy tools used to create software distributions, install and upgrade, were now fully functional.
Migration of the SYSTEM4 on to the new architecture was in full progress.
IFS Maintenance was the solution that had come the furthest.
This year Sun's Java started to spread its wings. IFS prototyped a graphical Java client using the same business logic as the Windows client - for the first time benefiting from the layered architecture.

Although functional, the prototype demonstrated that big graphical Java programs just didn't run fast enough on the hardware of the time. Instead IFS decided to go with real web clients (just using HTML). The first attempts were made using Oracle web server (OWS).
However, Java lent itself nicely to server development and IFS developed its first Java based product - IFS Event Server. The Event Server allowed business logic to proactively send events and notifications (such as e-mails and SMS messages) to clients and other interested parties.

1997

During the summer,
IFS released its first complete ERP application built entirely on the new Foundation1 platform - IFS Applications 98. This was a major milestone and a number of customer installations were done during 1997 and 1998.

The Foundation1 team was, like many software vendors, busy with the migration of the windows clients and frameworks from Win16 to Win32 platform. This migration was completed in October with the release of Foundation1 2.0. For this version, the Rational Rose tool had also been upgraded and UML was now the notation used for design.

With Java applets struggling to do anything but simple games and animations, server side scripting emerged as a faster and easier way of building "cgi type" applications that only relied on standard HTML in the browser. IFS found the combination of Microsoft Active Server Pages (ASP) and FrontPage to be a very productive environment for server pages. To make development of server pages easier, a framework of server-side components for business logic access, page formatting etc. was to be developed. Trying to avoid technology lock-in, the decision was made to implement these components in Java rather than a Microsoft-specific technology such as Visual Basic. Doing this, IFS was among the first companies to make use of the Microsoft Java SDK with its Java <-> COM interoperability capabilities. The Microsoft Transaction Service (MTS) was used to provide scalability.

The results of these efforts were packaged as an "add-on to Foundation1 for development of web user interface using Microsoft ASP and MTS". This package was dubbed the Web Kit - a name that should live for many years to come. Some prototype web solutions were developed for IFS Applications 98.

History of IFS Foundation1 (1994-1995)

1994

To define the "new" architecture and technology of IFS Applications, IFS R&D presented project Everest. The name Everest implied to set high goals and take a steep climb to "be on top".
The overreaching goals of project Everest were to:

• Perform BPR on the software development process used at IFS


• Become the most efficient software producer


• Development and assembly of application components


• A product that can follow the customers business development, as well as technology development


• Avoiding BIG-BANG
  

More specific goals included providing a graphical (Windows) user interface, a productive development environment, component thinking, use of object oriented design, and co-existence with SYSTEM4..

1995

This was the year when the core principles of the new architecture were established.
The architecture was to be 3-tier with business logic and data storage tiers running in Oracle, and the presentation tier built using Gupta SQL*Windows.
This architecture was dubbed Open Layered Architecture (OLA).
The applications were designed according to object orientation principles with business objects such as Customer, Supplier, Order, Invoice and so on.
Each business object had an implementation in all three layers of OLA.
The collection of these implementation was referred to as the Logical Unit (LU). Logical units communicated internally using private API:s and externally in the business logic tier using public API:s.

At the end of the year, Foundation1 consisted of a number of PLSQL system services to support implementation of business logic and a class library for Gupta SQL Windows. There was also the beginnings of life cycle support with some basic code generation and a first version of IFS/Localization tool.

The scope and functionality of Foundation1, which had now reached version 1.1,
was described using the nine components shown on the right.

Development of an IAL Object(Samples)

Development of an IAL-Object consists of the following steps.

1. Decide which data is required from the application
2. Create an .ial-file that defines this object
3. Deploy the object using Sql File Executor.
4. Set security using Security-tool, making it available to the end user

IAL Objects should be developed for access through any client based reporting tool.
This is how an .ial-file may look. Example taken from Foundation1 Demo application

-----------------------------------------------------------------------------
-- Component:
-- Purpose:
-- IFS/Design Template
-- Date Sign History
-- ------ ---- -----------------------------------------------------------
--
-----------------------------------------------------------------------------
define OBJECT = CUSTOMERS
define MODULE = INVADER
define AO = &AO
-----------------------------------------------------------------------------
------------------------ OBJECT REGISTRATION -------------------------
-----------------------------------------------------------------------------
-- Disable to be able to redeploy objects
begin
&AO..IAL_Object_API.Disable('&OBJECT');
end;
/
-----------------------------------------------------------------------------
------------------ VIEW FOR SELECTS ------------------------------------
-----------------------------------------------------------------------------
PROMPT Creating &OBJECT view
CREATE OR REPLACE VIEW &OBJECT._IAL AS
SELECT co.company_id Company,
co.name Company_Name,
cu.customer_id Customer_No,
cu.name Name,
cu.address Address,
cu.city City,
cu.phone Phone_No,
cu.type Type,
cu.total_order_value Tot_Order_Value,
cu.invoice_value Tot_Invoice_Value
FROM &AO..DEMO_COMPANY CO, &AO..DEMO_CUSTOMER CU
WHERE CU.COMPANY_ID = CO.COMPANY_ID
WITH read only;
GRANT SELECT ON &OBJECT._IAL TO &AO WITH GRANT OPTION
/
-----------------------------------------------------------------------------
--------------- TABLE FOR WAREHOUSE ---------------------------------
-----------------------------------------------------------------------------
CREATE TABLE &OBJECT._TAB
TABLESPACE &ial_data STORAGE (&normal)
AS ( SELECT * FROM &OBJECT._IAL WHERE 1=2 )
/
ALTER TABLE &OBJECT._TAB ADD (
CONSTRAINT &OBJECT._PK
PRIMARY KEY (COMPANY, CUSTOMER_NO)
USING INDEX TABLESPACE &ial_index STORAGE (&normal))
/
GRANT SELECT ON &OBJECT._TAB TO &AO
/
-----------------------------------------------------------------------------
--------------- OBJECT REGISTRATION ----------------------------------
-----------------------------------------------------------------------------
begin
&AO..IAL_Object_API.Enable('&OBJECT');
end;
/

How to create a LOV view for ifs portal as a List Value

Step by Step :

1. create a new LOV (View as below)
   
   DEFINE MODULE = INVENT
   DEFINE LU = InventoryPart
   DEFINE VIEW = TP_INVENTORY_PART_LOV
   PROMPT Creating report view &VIEW
   
   CREATE OR REPLACE VIEW &VIEW AS
   SELECT ip.part_no part_no, ip.description description, accounting_group_api.get_description(ip.accounting_group) acc_group_desc
   FROM INVENTORY_PART_TAB ip, user_allowed_site_pub ua, part_catalog_pub pc
   WHERE ip.type_code IN ('1', '2', '3', '4', '6')
   AND ip.contract = ua.siteAND ip.part_no = pc.part_no
   AND pc.position_part = 'NOT POSITION PART'
   AND ip.accounting_group = '010'AND ip.contract = '008'
   WITH read only;
   
   COMMENT ON TABLE &VIEW IS 'MODULE=&MODULE^LU=&LU^PROMPT=&LU^';
   COMMENT ON COLUMN &VIEW..PART_NO IS 'FLAGS=PMI-L^DATATYPE=STRING(25)/UPPERCASE^PROMPT=Part No^';
   COMMENT ON COLUMN &VIEW..DESCRIPTION IS 'FLAGS=A-IUL^DATATYPE=STRING(35)^PROMPT=Description^';
   COMMENT ON COLUMN &VIEW..ACC_GROUP_DESC IS 'FLAGS=A---L^DATATYPE=STRING(35)/UPPERCASE^PROMPT=Acc Group Desc^';
2. to add above LOV in ifs-portal (java source)
   ...
   public void preDefine()
   { ASPManager mgr = getASPManager();
   
   headblk = mgr.newASPBlock("MAIN");
   headblk.addField("OBJID"). setHidden();
   headblk.addField("OBJVERSION"). setHidden();
   ....
   headblk.addField("PART_NO").
   setMandatory(). setInsertable().
   setLabel("FCSTYEARPARTPARTNO: Part No"). setSize(25).
   setDynamicLOV("TP_INVENTORY_PART_LOV").
   setLOVProperty("TITLE",mgr.translate("FCSTYEARPARTPARTNO1: Part No"));
3. to USE devtool.exe with Scan the sources
   to put new LOV in databas efor security setting by Admin.exe
4. Grant user as below:
   GRANT SELECT ON TP_INVENTORY_PART_LOV TO IFSSYS;
5. re-Run the ifs-portal (http://lg:59080/)
   PATH:WebClient Administration folder
   --Clear Profile Cache/Clear Security Cache/Reload Configuration file

To Set Client Character Set in windows

--IFS Applications On Windows mode like localize.exe etc
use environment variables through NLS_LANG (Start > Control Panel > System-Advance)
--PLSQL etc tools in windows use environment variables
through the Registry Editor (Start > Run > Regedit).

More examples:
NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252
NLS_LANG = TRADITIONAL CHINESE_TAIWAN.ZHT16MSWIN950
NLS_LANG = SIMPLIFIED CHINESE_CHINA.ZHS16GBK
NLS_LANG = VIETNAMESE_VIETNAM.VN8MSWIN1258
NLS_LANG = JAPANESE_JAPAN.JA16SJIS