Progress
Developer’s Toolkit


CRC R-code

This section provides an overview of the steps to follow to deploy an application using CRC-based r-code. When you are done developing and testing your application and are ready to begin deploying, follow the steps described in the following sections. For a complete description of CRC-based r-code, see the Progress Programming Handbook.

If you deploy your application to users with full development products (the 4GL Development System, ProVISION, or ProVISION Plus), they can write their own applications to access the database and modify the database schema. Depending on the nature of your application, you might not want this to happen. To restrict access to the database, you can use the DBRSTRCT utility that comes with the Developer’s Toolkit. For more information about using this procedure, see the "Restricting Database Access" section in Deployment Topics and Tasks."

If you decide to restrict access to the database, you must physically deploy a copy of your application database with your application. It is not possible for users to build your database at their site. Because databases are not portable, you must generate a copy of the database for each target platform. Then you must run the DBRSTRCT utility on each platform against all of the databases.

In general, restricting access to the database makes it more difficult to initially deploy and upgrade applications, but it also helps minimize user-created errors. For each release of the application, the development site must:

To update the application, the user must dump the existing database and load the data into a new database that you supply. For users with large mission-critical databases, this might be an unacceptable requirement.

As described in Chapter 2, “Choosing a Code Format,” r-code is not completely portable. For each combination of factors requiring a separate compilation, you need to perform a separate compilation and keep track of a different code tree at the development site. For each combination, you also need a full development Progress product (the 4GL Development System, ProVISION, or ProVISION Plus)) to do the compilations.

Unless you explicitly specify the Time Stamp (-tstamp) startup parameter when you start Progress, Progress generates CRC-based r-code files at compilation.

NOTE: Progress Software recommends CRC-based r-code because it affords greater flexibility.

If you decide not to restrict database access, you should dump your application schema (.df) and/or data (.d) files into ASCII format. This step copies your data from the application database, which is not portable, into a format that is portable.

The .d and .df files should be represented with the appropriate code page for the target platform. For more information about character processing in Progress, see the Progress Client Deployment Guide .

You must transfer the resultant .d and .df files to the target platform.

There is more than one way to transfer files. For example, you can use FTP or other protocols, such as CROSSTALK. Or you can put the files on tape or other storage media and physically transport the files.

To aid in moving r-code files between platforms, you can use the BUNDLE utility. For more information about the BUNDLE utility, see Deployment Topics and Tasks."

If you have decided not to restrict access to the database, then you must provide a way for users to rebuild your application database at their site. To do this, users must be able to load your .df and .d files into an empty database.

NOTE: You can restrict access to the database and provide compiled code to load .d files.

Any Progress client, server, or stand-alone database product can run r-code. However, not all of these products can load .d files into a database. The 4GL Development System, ProVISION, and ProVISION Plus are the only products that have this capability.

If you deploy to users whose licensed products do not have this capability, you must provide a way for them to load your .d files. For more information about providing a dump/load facility for users, see the "Dumping and Loading" section in Deployment Topics and Tasks."

NOTE: The dump/load procedures should be considered part of your application. The decision to distribute r-code versions of your application procedures applies to the dump/load procedures as well.

The 4GL Development System, ProVISION, or ProVISION Plus products contain a complete Data Dictionary, which users can use to load the .df and .d files into an empty database. (In character environments, the Data Dictionary contains data administration capabilities. In Windows, these capabilities are provided with the Data Administration tool.) However, even though the user can perform these tasks, usually it is a good idea to write a script that automates this process. This not only frees the user from performing this task, but also makes your application easier to use.

Within your script, you can use pre-existing procedures in the DLC/tty and DLC/gui directories (installed for full development Progress products). Within these directories are procedures that load .df and .d files, called load_df.p and load_d.p, respectively. Your script can start Progress and run these procedures to load your data definitions and data. To run these procedures at user sites where users do not have a license for the 4GL Development System or ProVision, the procedures must be in r-code format.

If you decide not to write a script and instead rely on the users’ ability to load the data definitions and data, make sure you provide adequate documentation to guide them through the process.

To rebuild your application database at the user’s site, you must make a copy of the empty database and rename it. An empty database is included in the DLC directory of all Progress client, server, or stand-alone database products. Because databases are not portable, you must use an empty database that already is ported to the target platform.

Users can use Progress to copy the empty database and rename it. Or you can free them from this responsibility by writing a script that does this task for them. This script can call the PRODB command to make a copy of the database and rename it appropriately. The Developer’s Toolkit also provides a newdb script that creates a database.

If users have a Progress product that provide these capabilities, and you decide to let them perform this step, you must provide adequate documentation to guide them through the process. For example, you should let them know there are multiple empty databases, and you should recommend which one they should use.

You must provide a way for the user to install your application. Progress must be installed before they can use your application. You can create one install for both Progress and your application. To do this, create an install program using a third-party tool, such as Installshield, and call the Progress Install batch mode from within it.

You must provide a way for the user to start the application. You can write a script to do this or provide adequate documentation.

You must provide the user with enough documentation to use your application and to perform the above tasks if you do not automate them.

You might want to provide online help for your application. For more information, see the Progress Help Development Guide.

Now that you have completed the above steps, you need to prepare your distribution media. It should include:


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095