Sending and receiving partition files

Examples that show how you might use partitions to share data with another database. The first example shows how the process works if you are sending out data in a partition, the second example shows what you should do if you receive data in a partition file

Sending data in a partition file

  1. You create a partition definition, which defines what data to include in the partition, and what access rights users can have to the data when they import it. See Creating partition definitions.
  2. You export the partition, which creates a partition file, and copies the data defined by the partition definition to the file. See Exporting partition definitions.

    If you have given edit access to any of the modules in the partition file, Rational DOORS locks the copy in your database, making it read-only. Each module in the partition file is either read-only in your database or read-only in the partition.

  3. You send the partition file, in the same way as you would any other document file.
  4. The person who receives your partition file imports it into their Rational DOORS database. They work on the data within the constraints of the access rights that you have given. They can either send back synch files that contain updates to the data, or complete their work and send you a return file.
  5. If you receive a synch file, you synchronize your database with the updates that have been made in the remote database. Any locks associated with the partition remain in place. See Synchronizing an exported partition.
  6. When users in the remote database are finished updating the data, they create a return file and send it to you. When you rejoin this to your database, all the updates that have been made in the remote database are applied to your data. All the locks that were associated with the partition are removed. See Rejoining a partition.

Receiving data in a partition file

  1. Import the partition into your database. The data in the partition file is copied into your database with the access controls that were set at the originating database. See Importing a partition
  2. Update the data as required.
    Note: You do not have administrative access to objects that have been created from an imported partition. As a result you cannot perform administrative tasks, such as setting the modules up for shareable edit.
  3. To send updates back to the originating database as you work, you can create and send synch files. See Creating a synch file from an imported partition
  4. When you have finished updating the data, return the imported partition. See Returning an imported partition

    This creates a return file and copies the partition data to the file. You can choose to either:

    • Remove all the partition data from your database.
    • Keep the partition data in your database, but reset its status to make it look like normal local data.
Note: Although you can create a partition definition that includes modules that are part of an imported partition, this is not supported. You might find that you cannot rejoin or recover data to either partition.

Feedback