About On-premise and Cloud Database

InfoWorks WS Pro maintains model data in a centralised multi-user on-premise database, consisting of a database and additional files to facilitate both workgroup and standalone operations.

If you have an Autodesk Licence, the data can also be maintained in a centralised, multi-user database in the cloud. Like the on-premise database, the cloud database consists of a database and additional files.

Local working copies of parts of the on-premise and cloud data are then made available in each user's working folder.

On-premise and cloud database provides a flexible hierarchy for managing model data and contains all your model data and results. It consists of a database and directories containing supporting files including simulation results and ground models.

The following types of databases may be used:

Workgroup : An on-premise database intended for use by individuals and groups of users. Requires the use of the Workgroup Server software to manage access to these types of databases. The software was designed to improve the performance and reliability of database operations in a workgroup environment. To share the database as part of a workgroup, it must be located on a machine where it can be accessed by all users. The following types of on-premise workgroup databases are available:
- Standard (WorkGroup) Database
- SQL Server (WorkGroup) Database
- Oracle (WorkGroup) Database
SQL Server and Oracle databases require your own database installation.

On-premise workgroup databases are available with an Innovyze or an Autodesk licence.
Standalone: An on-premise database intended for use by individual users working on a single PC. This type of on-premise database is only appropriate for use on a standalone machine, and is available with an Innovyze or an Autodesk licence.
Cloud: A cloud database intended for use by individual and multiple users. Access to cloud databases is handled by the cloud data service, which is managed by Autodesk. This lets you take advantage of the unlimited storage capabilities of the cloud, and removes the need to set up and maintain an internal data server that is required for workgroup on-premise databases.
Note: Cloud databases are only available with an Autodesk licence.

When a database is created, local working copies of parts of the data are then made available in each user's Local Folders.

InfoWorks WS Pro includes comprehensive on-premise and cloud database management facilities, which let you organise your work logically and efficiently. Using these facilities you can see the overall structure of the database, break it down into its components, and view any part of the data itself.

Database formats supported

InfoWorks WS Pro uses its own workgroup server as the default database component of the database.

Support is also included for Microsoft SQL Server databases. If you already have a Microsoft SQL Server installation you can use this to create and manage databases of almost unlimited size.

Support is also included for Oracle databases, for which you must already have your own Oracle database installation.

Database versions

Each on-premise and cloud database has a version number. For example, a database created with version 2023.0 of the software will have a database version of 2023.0. You can choose which version of the database is to be used when you create a database. This can be useful if you collaborate with other users who do not work with the same version of InfoWorks WS Pro as you.

Note:

If you work with a database that is older than the version of the software you are using, for example, database version 2023.0 with software version 2023.1, you may not be able to access all the new features that are available in the newer version of InfoWorks WS Pro. The availability of a new feature depends on whether or not it requires database tables and fields, such as object properties or a database item, that are only available in the newer version of the database.
You cannot paste data copied from a database with a newer database version than the database you are pasting to.
You can update an older version of a database to a newer one. This lets you access all the features available in the newer version of the software. However, the updated database cannot be used, by you or any other user, in an older version of the software.

The version number of the currently selected database is displayed in the Explorer Window.

Organize your on-premise and cloud databases

Database location

InfoWorks WS Pro can be used as both on-premise or in the cloud.

For cloud databases, data is stored in the cloud for the tenant it was created for. For on-premise databases, the location of the various components of a database varies depending on which underlying database is being used.

If you want to share the database as part of a workgroup, the database must be located on a machine where it can be accessed by all your users.

Standard

When you create the on-premise database, you can choose the location of the database index file that forms the entry point to the database.

The files containing the database data are stored in a sub-folder of this location. The name of the sub-folder is the Unique Database Identifier for the database. If you have more than one database in the same folder, there will be a sub-folder for each database.

SQL Server and Oracle

The location of the on-premise database is controlled by the database server and you cannot change this location. The database can be on a server or on the local machine.

A SQL Server or Oracle installation will be visible across the network as long as the server is running.

Any additional files are stored in sub-directories of the Remote Root directories. The name of the sub-folder of each remote root is the Unique Database Identifier for the database. If you have more than one database there will be a sub-folder for each database.

You will get best performance for workgroup operation if you keep the database on a proper network file server.

When working as a single user, you will get the best performance if the database is stored on your local hard disk. Bear in mind that:

Databases can become very large.
You will have to move the database to a shared location before other users can gain access.

How many databases?

Ideally you will have just one database for your workgroup or even for your entire organisation. Some organisations have an extremely large (more than 20 GB) database using an Oracle or SQL Server database.

A consultant might choose to have a different database for each client. Water companies may divide their data based on geographical criteria.

If you have multiple databases, you can assign each one to a named group. (This is not to be confused with object groups within a database.)

Local folder

To facilitate workgroup operations, and to keep work in progress separate from the main data storage, InfoWorks WS Pro uses a local folder.

Note: The local folder should, if possible, be on the user's machine. If you access your local folder via a network you will seriously degrade the performance of InfoWorks WS Pro and you may also affect the performance of your network.

Each on-premise and cloud database has a sub-folder of the local working folder containing transitory data and the local results folder containing local results files.

The name of the sub-folder is the Unique Database Identifier for on-premise databases and the Unique Identifier for the cloud database. If using more than one database, there will be a sub-folder for each database.

The data stored in your working folder is called transitory data and is made up of the following:

Working copies of checked out networks.
Local results files.
Other temporary working files.

When you create a new database, a text file (DBVER.DAT), which contains the database path and the database version for the new database, is added to the Local folder, and, if applicable, the Remote Roots folder. If you update a database, the version number will also be updated in the text file. Similarly, if you rename a cloud database, the text file will be updated with the new name.

You should never have to access these local files directly. You can clean up unwanted local files from within InfoWorks WS Pro.

See Set the Local Folders for more details.

Remote roots

Some on-premise database data is not stored in the database file itself, but as separate files in remote root directories. The data most commonly stored in this way is simulation results. These tend to be very large and can reduce database performance.

Remote root folders do not have to be on the same drive, or even the same machine, as the on-premise database.

The location of the remote root directories can be changed.

When working with Microsoft SQL Server or Oracle databases you must set the location for your remote roots. The remote roots do not have to be on the same drive or even the same machine as the database. You only need one set of remote roots, even if you work with more than one database.

Files are always stored in a sub-directory of the remote root. The sub-directory name is the unique database identifier for the on-premise database.

See Remote Roots for more details.

Creating databases

An on-premise or cloud database is created using InfoWorks WS Pro.

SQL Server or Oracle databases are created using the creation tools supplied with the database installation. Autodesk provides scripts to format the new database correctly.

You can also create and update transportable databases, which have a similar format to on-premise or cloud databases. Transportable databases store copies of some or all the data from an InfoWorks WS Pro on-premise or cloud database for copying and backup purposes. Archives allow you to store data for future use.

Structure and contents

InfoWorks WS Pro includes data management facilities that let you organise your work logically and efficiently within the database.

The database can be viewed using the Explorer Window or the Model Group Window. The Model Group window is the most convenient for day to day work, as it can be docked (attached) to the side of the InfoWorks WS Pro main window.

The general structure of the database is:

The database contains one or more model groups.
Model groups can contain other model groups, version controlled items, and data groups.
Data groups can contain other data groups of the same type and database items of the correct type for the group.

Item types

Some items, such as networks, are version controlled items. These provide a safe and structured way of creating successive versions to test potential changes, or going back to a previous version and branching to explore other scenarios.

Other model data, such as electricity tariff data, is stored in data groups. Groups can be embedded within groups to provide structured storage.

Item names

Item names can be up to 80 characters long, and must not be blank. Names can contain spaces.

The names of version controlled items must be unique within a database.

All other names must be unique within that type and its parent. For example, two data groups of different types within a model group can have the same name, but two groups of the same type must have different names.

Protecting items

Database items are marked as protected from deletion when they are used in simulations to prevent loss of critical data.

Once database items have been used in a simulation, they cannot be altered or deleted.

You can override these protections and clean up redundant model runs and data.

General structure

Version controlled items reside within model groups. Version controlled items need to be checked out before editing. Checked out items are shown with a red border to the icon.

If you carry out a run with a checked out network, the run icon is shown with a red border. The simulation icons contained under the run icon will have a red border if the control data set used for the simulation was checked out.

The colour of the run icon indicates the run type. The available types are:

	Normal Run
	Automatic Calibration Run
	Water Quality Run
	WatSed (sedimentation) Run
	Fire Flow Run
	Critical Link Analysis Run
	Shutdown Run
	Flushing Run
	Leakage Locator Run
	InfoWorks TS (Transient System) Run

Other data is stored in data groups, and groups can be embedded in groups.

See Database Items for a list of all the version controlled items and groups that make up a cloud or on-premise database.

Database identifier

Each on-premise database has a unique database identifier. When you create a new database, this identifier is generated automatically and is a string of letters and numbers guaranteed to be unique (e.g. 629810C2-3F6B-11D3-9BF3-00600891B690). Unique database identifiers can be set manually. For instance, the identifier for the example database usually takes the form IWExamples123.

Each cloud database has a Unique Identifier. When a new database is created, this identifier is generated automatically as a string of 26 letters or numbers: 01FR0B5XYXVHGTD39BF3VGV6O.

Version control

Version control allows a modeller to record major changes to a network model providing a permanent record and enforcing a standard on the calibration process. It also means that a previous model can always be revisited as a starting point if the final version is unacceptable.

If different scenarios are being investigated a model can be branched from the base model and modified independently. In this situation it is at the discretion of the individual modeller how often the model is checked back in because his modifications are independent of the base model being used by other colleagues.

Once a model has been calibrated and authorised by the manager of the modelling team, the final model may be copied to a designated secure location in the audit trail and intermediate network models removed. However the process of arriving at the final model is still available until authorisation.

See Managing Version Controlled Items for more information.

Database administration

Further database protection is available to administrators. Some more sensitive database operations, such as deleting data in bulk, can only be carried out by administrators.

Copying on-premise or cloud databases

Note: You should never use the methods provided by the database application to copy an Oracle or SQL Server database and then carry on using the new and original databases.

You should never copy an on-premise or cloud database, rename the copy, and then carry on using the new and original databases. Every on-premise or cloud database has a unique database identifier. This identifier is 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 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 well be based on the same root network, it could be difficult to spot that these problems are occurring.

The correct way to copy data, for both cloud and on-premise databases, is to create a new database, and then open the existing database as a guest to copy data from. Alternatively, use a transportable database to transfer data from the old to the new database. This may seem a long winded approach but it is designed to:

Let you copy data into a new database or an existing database that already contains data.
Protect the integrity of your data in both databases.
Support copying data between databases of different types.

Transportable databases

Note: Results files can be very large and including them in a transportable database may take a considerable length of time. It will often be more efficient to transfer the result some other way, such as on a disk, or to regenerate the results later when data is copied out of the transportable database.

Transportable databases allow you to copy data between databases, even if the databases are of different types. Transportable databases have the same internal format as an on-premise or cloud database, and allow you to maintain the full structure of the data you are copying.

You would use a transportable database to:

Copy data from one database to another.
Share data with other departments or external consultants.
Send data to Autodesk as part of a support request.

All types of data can be copied into a transportable database, including results files from your remote root directory.

See Transportable Databases for more details.

Delete data

Data can be deleted from the database only before the data is used. Once data is marked as used in a simulation, it is protected from deletion by the database management system.

These protections can be overridden by administrators. See Deleting data for more details.

Backing up data

However you choose to organise your model data, it is essential that you operate a sensible backup procedure to protect mission critical data and information.

You must back up your database - the database file and the directories containing supporting files (for example, simulation results and ground model files).

You should not need to back up your working folder. The only things you would lose if the directory is destroyed are changes to checked out networks since they were last checked out, and local results files.

See Backing up Your Data for more information about carrying out backups.