Copying data between databases

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, 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 in order to transfer the data.

Copying and pasting

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:

copying version controlled items on their own or with children
pasting a version controlled item as the next version or pasting as a branch

There are two ways that you can use to copy the database:

Copy between databases - this will copy the database or model group but retain the type of version controlled object, i.e., it will not convert to use the merge version control.
Copy within databases and convert to merge model - this will copy and convert an entire database or model group to use the merge version control. Refer to Paste and Convert to Merge Model for details.
Notes:
- This method only allows copying within databases. It does not allow copying between databases.
- It is not possible to copy to a cloud database and convert to merge model at the same time.

To copy data between databases:

Make the database that you want to copy from the current database.
Display the current database in the Explorer window.
Open another on-premise or cloud database or a transportable database for copying:
- For on-premise or cloud database, select File | Open | Open another database as guest and choose the required database. (Multiple guest databases may be opened.)
- For a transportable database, select File | Open | Open transportable database and choose the required database. (Multiple transportable databases may be opened.)
In the Explorer window for the current database, right-click the top level of data you want to copy.
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).
For items that are not version controlled, select Copy | Select for moving from the context menu.
For networks and other version controlled items, select one of the two sub-menu options:
- On its own (copy the selected version controlled item only)
- With children (copy the selected version controlled item along with all its versions and branches)
In the Explorer window for the database to be copied to, right-click the item that is to contain the copied data and select Paste from the context menu.

To copy within databases and convert to merge model:

Select File | Database settings and select the Use merge version control option.
Ensure that networks and controls are checked in. Versions that are checked out will be excluded from the conversion.
Display the current database in the Explorer window.
Open another on-premise or cloud database or a transportable database for copying:
- For on-premise or cloud database, select File | Open | Open another database as guest and choose the required database. (Multiple guest databases may be opened.)
- For a transportable database, select File | Open | Open transportable database and choose the required database. (Multiple transportable databases may be opened.)
In the Explorer window for the current database, right-click the top level of data you want to copy, and then select Copy from the context menu.
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).
For items that are not version controlled, select Copy | Select for moving from the context menu.
For networks and other version controlled items, select one of the two sub-menu options:
- On its own (copy the selected version controlled item only)
- With children (copy the selected version controlled item along with all its versions and branches)
In the Explorer window for the database to be copied to, right-click the item that is to contain the copied data and select Advanced | Paste: [Model Group] and convert to merge model from the context menu.

Notes:

It is not possible to paste data from a cloud database into an on-premise database directly. A message will be displayed if you try to do so.
You can copy networks that originated from a cloud database from a transportable to an on-premise database (standalone or workgroup database).
It is not possible to copy to a cloud database and convert to merge model at the same time.

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.

Do not use Windows Explorer or File Explorer to copy databases

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.

Notes

Between versions

If you copy from an on-premise database to a cloud database, it does not copy checked in and checked out version controlled objects. A message window will appear detailing the items that will not be copied.
It is not possible to paste data from a cloud database into an on-premise database. A message will be displayed if you try to do so.
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.

Paste and convert to merge model

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:

This method only allows copying within databases. It does not allow copying between databases.
It is not possible to copy to a cloud database and convert to merge model at the same time.

Using this option, the lock version objects are converted to merge version objects as follows:

Checked in versions become to commits in the merge tree.
Checked in branch versions become branches in the merge tree.
Items that remain checked out are not converted. A warning message will be displayed.
The new merge tree’s commit history shows the origin of commits and branches.

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.

Duplicate objects

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:

If you click OK to continue to paste the objects, items that already exist in the database will be duplicated there. The duplicate items are identified by appending an exclamation mark (!) to the item name to create a unique name from the old name and a new unique identifier is generated.
If you click Cancel, no data will be copied (regardless of whether it is duplicate or not).

Objects are not overwritten.

Runs and simulation results in on-premise databases

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:

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

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.

Runs and simulation results in cloud databases

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.

Relationships

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.

Workspaces

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.

Baselines

When a baseline is copied between databases, IWLive Pro workspace information is not automatically copied. IWLive Pro workspaces contain layout, formatting, contents, and sizing settings for the windows that are currently opened in IWLive Pro.

These formatting parameters are saved per user and are stored in IWLive Pro workspaces so they can easily be re-used.

It is possible to copy IWLive Pro workspace information by right-clicking the source database entry in the Explorer window and selecting Copy IWLive Pro workspace. Paste it in the target database by selecting Paste IWLive Pro 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.