Data can be copied between two on-premise or two cloud databases, between an on-premise or a cloud database and a transportable database, or between two transportable databases.
A non-current on-premise database can be opened as a guest database to copy data between two on-premise databases on the same machine or network, or two cloud databases on the same hub and project, or between an on-premise database and a cloud one.
Note: You can paste data copied from an on-premise database opened as a guest into a cloud database but you cannot currently paste data from a cloud database opened as a guest into an on-premise database.
A transportable database may be used for transferring data:
Between on-premise databases in an organisation.
Between cloud databases in an organisation.
Between on-premise databases and cloud databases in an organisation.
When sharing data with external organisations. If you are sharing data from a cloud database, the external organisation must also have access to the relevant hub and project in order to transfer the data.
Objects are copied and pasted between databases in the same way as within a database, except that version controlled items can be copied.
Copying and pasting is recursive. When an object is copied, all descendants of the object are copied with it. For example, if you copy a stored query group, all queries and stored query groups contained in the parent stored query group will also be copied.
Version controlled items are not subject to this rule. You will be given the option of:
There are two ways that you can use to copy the database:
To copy data between databases:
For example, you can choose a whole model group or any item in a model group (such as a network or a selection list group).
To copy within databases and convert to merge model:
For example, you can choose a whole model group or any item in a model group (such as a network or a selection list group).
All items of data at or below the selected level will be copied. Note that you can only paste the data into an item of the correct type. For example, if you copy a selection list, this must be pasted into a selection list group.
You can repeat this process as often as necessary, so that any combination of data items is copied to the database.
You should never copy a on-premise or cloud database using Windows Explorer or File Explorer, rename the copy, and then carry on using the new and original databases.
You should never use the methods provided by the database application to copy a SQL Server database and then carry on using the new and original databases.
You should never use the methods provided by the database application to copy an Oracle database and then carry on using the new and original databases.
The only completely safe solution is to never, ever, copy on-premise or cloud databases using Windows Explorer or File Explorer.
Every on-premise database has a unique database identifier, and every cloud database has a unique identifier. These identifiers are used to manage files in the working folder, and in some circumstances, files that form part of the database itself.
If you work with two databases that have the same unique database identifier/unique identifier your working files will get mixed up and you run a very real risk of losing or corrupting data. Because your working copies of networks may be based on the same root network, it could be difficult to spot that these problems are occurring.
Data can be copied between databases that have different database versions. You can paste data copied from an older version of a database into a newer version but you cannot paste data copied from a newer version of a database into an older version, unless you update the older version to the same version as the newer database.
The Paste and convert to merge model option will convert an entire database or model group to use the merge version control. A copy of the model group(s) is created while the original model groups are left unchanged. All versioned objects are converted to the merge model of version control. Runs and other objects are copied and modified to use the new objects.
Notes:
Using this option, the lock version objects are converted to merge version objects as follows:
Databases or model groups of versioned objects that are already in the merge style are copied without modification.
Runs and other objects are copied, and their references are updated. Baseline objects are copied but not converted. If runs or baselines reference items that exist in different model groups, then those items will also be copied, and they will be placed in copies of their own model groups.
All objects in an InfoWorks WS Pro database (on-premise, cloud, or transportable) are identified by a globally unique ID (GUID).
InfoWorks WS Pro checks if objects being copied to a database already exist in the database. If there are duplicate objects, the Copying Of Duplicate Items dialog will be displayed:
Objects are not overwritten.
If runs or simulation results are copied between databases, any associated data needed to reproduce the run will also be copied as long as you follow the correct procedure.
Note: To copy associated data automatically, you must paste the run into a model group in the destination database. This includes the root (top level) model group.
If you paste the run into a run group in the destination database, then:
See the notes on relationships, below. The recommended practice is to organise your data sensibly in model groups and then to copy entire model groups between databases.
When copying simulation results, the Copying of Simulation Results and Ground Models dialog is displayed. This lists the simulation results that have been selected for copying. Note that you can choose not to copy simulation results or ground models. The ability to leave results and ground model data out of the copy operation is quite useful as this data is potentially very large. Any model data required to reproduce a run will always be copied.
Note: When copying simulation results that are stored locally, rather than on the server, the copy operation will be successful only if the two databases share the same remote root directory. See Managing results if you do not know where your results are stored.
If runs are copied from a cloud database, any associated data needed to reproduce the run will also be copied as long as you follow the correct procedure.
If you paste the run into a Run Group in the destination database then:
If the associated data (for example, the network) has previously been copied into the destination database, InfoWorks WS Pro will restore the relationships between the run and this data.
If the associated data is copied after the run, relationships will not be restored.
The recommended practice is to organise your data sensibly in model groups and then to copy entire model groups between databases.
Simulation results for any
Run included in a copied cloud database will not be pasted into
InfoWorks WS Pro. However, the simulation status icon for results unavailable () will be displayed under applicable runs in the
Explorer Window when the Run is pasted into the destination database in
InfoWorks WS Pro. If you want to view the result for such a simulation, you will need to re-run it in
InfoWorks WS Pro.
When objects contain references to other objects, you should try to copy all the objects together so that these relationships are maintained.
If the objects are copied separately, the objects being referred to must be copied before the objects doing the referring.
If you attempt to copy data that refers to items that do not yet exist in the database being copied to, the Unresolved References dialog will be displayed. If you continue with the transfer, the reference data will be lost. You will not be able to restore the references later.
When you copy a workspace between databases, InfoWorks WS Pro will automatically copy all the underlying data required to recreate that workspace in the new database. You do not need to select this data yourself. This extremely powerful feature enables you to transfer complete projects easily and simply between databases. Remember that checked out version controlled objects are not copied.
When a baseline is copied between databases, IWLive Pro Operator Client workspace information is not automatically copied. IWLive Pro Operator Client workspaces contain layout, formatting, contents, and sizing settings for the windows that are currently opened in IWLive Pro Operator Client.
These formatting parameters are saved per user and are stored in IWLive Pro Operator Client workspaces so they can easily be re-used.
It is possible to copy IWLive Pro Operator Client workspace information by right-clicking the source database entry in the Explorer window and selecting Copy IWLive Pro Operator Client workspace. Paste it in the target database by selecting Paste IWLive Pro Operator Client workspace from the context menu.
Note: When copying baselines between databases, the baseline (or the model group containing the baseline) should be copied first, before the workspace is copied.
If the workspace is copied first and the baseline object does not exist in the destination database, a warning will be displayed.