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. For a complete description of CRC-based r-code, see R-codeFeatures and Functions.

1. Decide whether to restrict database access — If you deploy your application to users with full development products, 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 OpenEdge. For more information about using this procedure, see Restrictingdatabase access .

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.

2. Compile your procedures and include files — As described in Choosinga 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 OpenEdge product to do the compilations.

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

3. Dump .df and .d files — 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.

There are several ways to transfer files. For example, you can use FTP or other protocols, or you can put the files on CD or other storage media and physically transport the files.

5. Transfer r-code files — To aid in moving r-code files between platforms, you can use the BUNDLE utility. For more information about the BUNDLE utility, see DeploymentTopics and Tasks.

6. Rebuild the application database at the user site — 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.

Any OpenEdge client, server, or stand-alone database product can run r-code. However, not all of these products can load .d files into a database. Full development products 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 Dumping andloading .

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.

Full development 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. Progress Developer Studio for OpenEdge provides the Database Navigator.) 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 install-dir/tty and install-dir/gui directories (installed for full development OpenEdge 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 OpenEdge 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 OpenEdge, 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.

7. Copy an empty database and rename it — 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 installation directory of all OpenEdge 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 OpenEdge 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. OpenEdge also provides a newdb script that creates a database.

If users have an OpenEdge 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.

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

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

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