Copying Runs Between Databases

The Rangecam Office System can copy entire runs from one database to another. This has two main purposes:

1. Copying runs to an Enterprise database from the Access databases in which they have been prepared and edited.

2. Copying runs from one Access database to another during database reorganization.

If you use Rangecam Enterprise, you should import track test data to an Access database first for cleanup and alignment with other runs, before copying the finished product to your Enterprise database. That practice has two main benefits. One is that Enterprise database performance will not be affected by the high processing load of data cleanup and alignment operations. The other is that unfinished data, which may contain errors in location and rail section identification, is kept out of the Enterprise database, where it would potentially confuse end-users.

To copy runs from one database to another, first open the target database (the one to which the runs will be copied). If copying runs to an Enterprise database, it is the target. From the Profile Window menu, select Database\Import\Copy Runs… A special version of the Open Database dialog will appear (follow the instructions for opening an Enterprise level database).

This dialog is used to connect to the source database, containing the run(s) you wish to copy. When you click OK, you are presented with a dialog allowing you to select which of the runs in the source database to copy.

Copying runs from one database to another requires Rangecam to match subdivisions, rail types, rail classifications and other data items between the two databases. Before copying runs, you must ensure that all rail types and classes referenced by those runs already exist in the target database. If they do not, an error will occur.

Subdivisions have two unique identifiers in a Rangecam database - number and name. Target database configured to control the rule Rangecam uses to match subdivisions in the source and target databases. If rule is Name, Rangecam will associate the imported run with a subdivision in the target database that exactly matches the name of the subdivision in the source database. Note: spelling, and punctuation if any (such as spaces in the name), must match exactly. If rule is Number, then the run will be imported to a subdivision with the same number as in the source database. If there is no matching subdivision in the target database, one will be created.

If subdivisions are primarily identified by number in your organization, database should have Number in configuration. If subdivision name is the more important (or only) identifier, and subdivision names are spelled consistently in the source and target databases, database should be configured with Name. The effect of the Subdivision Key rule can be seen in the following example.

If Name rule is applied as the key on which to match subdivisions, then run 102 will be copied to subdivision 3 - SUNPEAKS in the target database, run 103 will be copied to the subdivision 2 - XANADU, and run 101 will be copied to a newly created subdivision 4 - FLAT BUSH. If Number rule is applied, then run 101 will be copied to subdivision 1 - FLATBUSH, run 102 to subdivision 2 - XANADU, and run 103 to subdivision 3 - SUNPEAKS.

If the copied run has any associated track points or exceptions, they will also be copied to the target database. Any required track point types or exception types will also be copied, if they do not exist in the target database.

Track segments associated with the run are not copied over, however, as copying segments could have unwanted side effects. If track segments need to be updated in the target database, they should be recalculated or entered manually.

The average wear values used for calculating trends are not copied with the run, because they are associated with track segments. Average wear should be calculated for the imported run after it has been copied, and track segments have been updated. Inventory also should be calculated after the run has been copied. Note: If a track segment is modified with historical profile runs attached, the historical runs must be recalculated.

Track location records of the distances between mileposts are not copied either, since they are not associated with any run in the database. As a result, if a run is copied from one database to another, the distances between mileposts are lost.