Application Data Set Limitations and Recommendations

This section lists some limitations and recommendations for Application Data Sets.

Limitations

Keep in mind the following limitations for Application Data Sets:

  • The Application Server and Process Scheduler used must both be able to access the project files using the same path. This will require that both are running on Operating Systems that use compatible file access conventions. For example, Microsoft Windows and UNIX-derived operating systems do not have compatible native file access conventions.

  • Although data set security has been improved in PeopleTools 8.54, and is more secure than some other migration technologies, data migration via ADS is intended to be used for data that does not contain sensitive data.

  • The data set definition must exist on the target database before you load a data set project to the target database.

  • The shape of a data set is defined by the records and fields included in the data set. The allowed shape changes include adding records or fields to a data set definition. Allowed shape changes do not require PeopleCode.

    Additional shape changes, such as supplying data values for a newly added field or moving data from one record to another may require a custom transform program. The application classes associated with data sets can support various data transformations expressed using the rowset PeopleCode API. In 8.53 transforms are possible at copy from file time, and in 8.54 and beyond transforms can be implemented at both copy to and from file times.

  • Data set records must be physical records that have at least one primary key. All child records must include the primary keys of the parent record, but may also have additional primary keys.

Recommendations

The following practices are strongly recommended:

  • ADS projects are meant for relatively small data sets of relatively static data.

    Note: ADS projects are not recommended for large data sets.

  • Do not change the source ADS Project file after the compare has been performed. If the source data file is changed, any compares must be re-run.

    Note: The decision of which objects to copy is based on the compare report, which is stored in the database. If the ADS project is changed after the compare, you may not get the desired results. Changing the target database may be necessary to fix validation errors, but caution is required to avoid changes to the target database that might create validation errors during copy that were not seen in compare.

  • Setting up the Project Repositories and areas is a one time activity. The directories should first be created by a system administrator with read/write access permissions for the users who will start the application and process schedule servers.