Kbase P12310: Are there any issues with loading common .df's,.d's, and run
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
1/31/2003 |
|
Status: Unverified
GOAL:
Are there any issues with loading common .df's,.d's, and runtime code across different sites with 3 different Progress minor versions?
FIX:
There is an explanation of running different Progress versions online at Progress Documentation
Part of this documentation is found below:
Progress Portability Guide
--------------------------------------------------------------------------------
1 About Progress Portability
Progress applications are portable across various architectures. This chapter presents an overview of Progress portability.
This chapter covers the following information:
The dimensions of Progress portability
Progress portability with and without recompiling
Designing Progress applications
Designing for portability
1.1 The Dimensions of Progress Portability
Progress applications are portable. If you follow certain guidelines and strategies, you can port Progress applications across:
Windows (32-bit platforms), UNIX, and AS/400 operating systems
Graphical and character display architectures
Progress databases and non-Progress data sources
The rest of this chapter introduces Progress portability guidelines and strategies.
This topic is discussed at length in the Progress Portability Guide in the Progress documentation
A portion of this book is contained below:
1 About Progress Portability
Progress applications are portable across various architectures. This chapter presents an overview of Progress portability.
This chapter covers the following information:
The dimensions of Progress portability
Progress portability with and without recompiling
Designing Progress applications
Designing for portability
1.1 The Dimensions of Progress Portability
Progress applications are portable. If you follow certain guidelines and strategies, you can port Progress applications across:
Windows (32-bit platforms), UNIX, and AS/400 operating systems
Graphical and character display architectures
Progress databases and non-Progress data sources
The rest of this chapter introduces Progress portability guidelines and strategies.
1.2 Progress Portability With and Without Recompiling
When you compile a Progress application, the compiler generates r-code. You can often port the r-code without recompiling. You must recompile only if one of the following changes;
The display architecture
The database type
The platform class
R-code version
1.2.1 Display Architectures
The two display architectures supported by Progress are graphical and character.
Code that does not contain user-interface statements (specifically, code that does not create frames, either explicitly or implicitly) does not belong to any display architecture, and so does not involve a change of display architectures. An example of such code is a batch program.
1.2.2 Database Types
Database types are Progress, ORACLE, ODBC-compliant, and DB2/400. Applications access non-Progress databases through the appropriate Progress DataServer products.
Code that does not access any Progress or non-Progress database does not belong to any database type, and so does not involve a change of database types. An example of such code is a date-conversion procedure.
1.2.3 Platform Classes
Platform classes are the AS/400, and all other platforms that Progress supports.
The class of a platform depends on its machine word size and byte alignment.
1.2.4 R-Code Version
Porting across r-code versions sometimes requires recompiling. The r-code version always changes between major releases. It may or may not change between minor point releases depending on the added functionality.
If you port to:
a lower or higher major release, you must recompile.
a higher point release within a major release, you do not need to recompile.
a lower point release within a major release, you may or may not need to recompile. However, it is highly recommended that you recompile.
1.2.5 Examples of Portable and Nonportable R-Code
Some r-code is portable, and some is not. You can usually port r-code between cl.ients as long as you do not change display architectures, database types, platform classes or major r-code versions.
Here are some examples:
If you port a Windows application to character-mode, you must recompile, because the display architecture has changed.
If you port a character application compiled against an ORACLE DataServer on a SUN workstation to a character application accessing an ORACLE DataServer on a Hewlett-Packard (HP) workstation, you do not have to recompile (assuming that the ORACLE release level does not change).
If you port a character application compiled against the DataServer for ORACLE on a SUN workstation to a character application accessing the DataServer for ODBC on an HP workstation, you must recompile, because the database type has changed.
If you port an application from Version 9.0 to Version 9.1, you do not have to recompile. If you port the application from Version 8.1 to Version 9.0, you do have to recompile. If you port the application from Version 8.3 to Version 8.2, you may not have to recompile, but it is highly recommended that you do so.
For more information on r-code portability, see the "R-code Portability and DataServers" section in Chapter 2, "Database Design," and the "R-code" section in Chapter 4, "Programming Considerations." For detailed information on r-code features and functions, see the "R-code Features and Functions" appendix in the Progress Programming Handbook.
1.3 Designing Progress Applications
To design a Progress application, follow the same basic steps whether you are designing for a single platform or for portability. Generally, the steps are:
Designing the database
Designing the user interface
Designing the trigger code
1.3.1 Designing the Database
Designing the database involves designing the database tables, records, fields, indexes, sequences, primary keys, and foreign keys that the application interacts with.
For more information on database design, see the Progress Database Design Guide and the Progress DataServer Guides.
1.3.2 Designing the User Interface
Designing the user interface involves creating the visual objects that application users interact with. The visual objects might include any of the following: database fields, queries, browsers, frames, rectangles, images, radio sets, toggle boxes, sliders, buttons, selection lists, editors, combo boxes, fill-ins, text, ActiveX Controls, SmartFolders, SmartPanels, SmartDataBrowsers, SmartDataViewers, SmartQueries, and SmartContainers.
For more information on user-interface design, see the Progress AppBuilder Developer's Guide, Progress Application Development Environment ¾ Getting Started manual and the Progress Programming Handbook.
1.3.3 Designing the Trigger Code
Designing the trigger code consists of writing the code (generally Progress 4GL code) that defines what the application does when the user interacts with the user-interface elements. For example, the application might write a particular database record when the user clicks on a particular button. In this case, the trigger code is the code that writes the record when a user clicks on that button.
For more information on using the Progress 4GL to write trigger code, see the Progress Language Tutorial (Windows or Character), the Progress Programming Handbook, and the Progress Language Reference.
1.4 Designing for Portability
When you design a Progress application for portability, you follow the same basic steps and consider the portability concerns of each step. The steps are:
Designing the database
Designing the user interface
Designing the trigger code
The portability concerns of each step are discussed in the following sections.
1.4.1 Database Portability Concerns
Database portability concerns include database-object naming conventions, multiple code pages, Progress and non-Progress data types, arrays, r-code portability across DataServers, and the behavior of certain .Progress 4GL statements across DataServers.
For more information on database portability concerns, see Chapter 2, "Database Design."
1.4.2 User Interface Portability Concerns
User interface portability concerns include using multiple layouts for different interfaces, specifying layout in character units or pixels, avoiding widget techniques that work only in a particular interface, screen formatting, colors and fonts, environment files, and events.
For more information on user interface portability concerns, see Chapter 3, "User Interface Design."
1.4.3 Code Portability Concerns
Some code portability concerns include: file naming conventions, terminal key definitions, operating system statements, preprocessor directives, database trigger storage, database names, record locking, and security.
For more information on code portability concerns, see Chapter 4, "Programming Considerations.".