The Rangecam Office System can copy entire runs from one database to another. This has two main purposes:
Copying runs to an Enterprise database from the Access databases in which they have been prepared and edited.
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 or runs 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. The Subdivision Key radio button allows you to control the rule Rangecam uses to match subdivisions in the source and target databases. If you choose 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 you choose 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, you should choose Number. If subdivision name is the more important (or only) identifier, and subdivision names are spelled consistently in the source and target databases, you should choose Name. The effect of the Subdivision Key option can be seen in the following example.
|
Source Database Subdivision |
Target Database Subdivision |
|||
|
Run |
Number |
Name |
Number |
Name |
|
101 |
1 |
FLAT BUSH |
1 |
FLATBUSH |
|
102 |
2 |
SUNPEAKS |
2 |
XANADU |
|
103 |
3 |
XANADU |
3 |
SUNPEAKS |
If Name is selected 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 is selected, 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.