What is shared in Tekla Model Sharing

Tekla Structures
2021
Tekla Structures

What is shared in Tekla Model Sharing

By default, all the model data is shared when you share a model in Tekla Model Sharing.

How data is shared in Tekla Model Sharing depends on the type of the shared data.

  • Some data is shared incrementally.

    This means that only the new and changed data is shared. When you read in, the data that is fetched from the sharing service is merged to the data on your computer.

    Note:

    You cannot remove or replace incrementally shared databases. The compatibility of incrementally shared databases is checked when the model is opened.

  • Some data is shared, but it cannot be updated incrementally.

    When you read in, the data that is fetched from the sharing service overwrites the data on your computer.

  • Some data is not shared.
    • Empty folders under the model folder are not shared.

    • By default, Organizer data is not shared.

      However, you can use the Organizer import and export with Tekla Model Sharing to share Organizer changes.

    • Backup copies of the model database, or .bak files, are not shared.

Note:

Some of the catalog files that are located in the environment folders (rebar_database.inp, assdb.db, screwdb.db, matdb.bin, profdb.bin) are copied to the model folder when the sharing is started.

How data is shared

If you want to check the files that have been overwritten when you read in, click File > Sharing > Open file backup folder to open the \ModelSharing\BackUpEnv folder under the model folder. The folder contains overwritten files from the three latest read ins. You can then, for example, copy the files back to your model or check the files for change detection.

Note:

We recommend that you do not remove or replace any databases. If you remove or replace a database, you must create a new baseline of the model. All other users must then join this new baseline, and then continue reading in packets.

Databases

Description

Model database

Model database .db1 is shared incrementally.

Numbering database

Numbering database .db2 is shared, but it cannot be updated incrementally.

If you have modified the family numbering settings and you read in, you lose the changes if another user has changed the family numbering settings and has written out.

Note:

We recommend that one user updates and shares the numbering settings with other users by writing them out. In case the user needs to read in before writing out the numbering updates, it is important to check that the settings are as they were before starting to share them.

We recommend you to use the Number series of selected objects command on the Drawings & reports tab when numbering.

Create your model output, such as drawings, reports, NC files and IFC files, after a successful write out.

Model history database

Model history database history.db is shared incrementally.

Plan database

Plan databases .db3 are shared, but they cannot be updated incrementally.

If you have imported a CIS/2 or a SDNF model and you read in, you lose the plan database changes if another user has imported the same CIS/2 or SDNF model and has written out.

Analysis model database

Analysis model database .db6 and analysis results model database .db5 are shared, but they cannot be updated incrementally.

If you have modified an analysis model and you read in, you lose the analysis model changes if another user has changed the same analysis model and has written out.

Custom components and sketched profiles

Custom components and sketched profiles database xslib.db1 is shared incrementally.

Standard-part model database

Standard-part model .db1 is shared when you save the standard-part model in a separate folder under the model folder.

Ensure that XS_STD_PART_MODEL is set relative to the model folder and that it points to the correct standard-part model, for example, XS_STD_PART_MODEL=.\StandardParts\.

Catalogs

Description

Profile catalog

Shared model contains the profile catalog file profdb.bin.

When you add and use a new profile definition in the shared model, the definition is shared the next time you write out. When another user reads in this new definition, the profdb.bin file in the user's model folder is updated to include the added definition.

You can also update the profile catalog with new definitions without creating any new objects or change the existing profile definitions of a profile that is already used in the model. For more information, see the 'How to share catalog updates' section below.

Rebar catalog

Shared model contains the rebar catalog file rebar_database.inp.

When you add and use a new rebar definition in the shared model, the definition is shared the next time you write out. When another user reads in this new definition, the rebar_database.inp file in the user's model folder is updated to include the added definition.

You can also update the rebar catalog with new definitions without creating any new objects. For more information, see the 'How to share catalog updates' section below.

Bolt catalog

Bolt assembly catalog

Shared model contains the bolt catalog file screwdb.db and the bolt assembly catalog file assdb.db.

When you add and use a new bolt definition or bolt assembly definition in the shared model, the definition is shared the next time you write out. When another user reads in this new definition, the screwdb.db and assdb.db files in the user's model folder are updated to include the added definition.

You can also update the bolt catalog and bolt assembly catalog with new definitions without creating any new objects. For more information, see the 'How to share catalog updates' section below.

Material catalog

Shared model contains the material catalog file matdb.bin.

When you add and use a new material definition in the shared model, the definition is shared the next time you write out. When another user reads in this new definition, the matdb.bin file in the user's model folder is updated to include the added definition.

You can also update the material catalog with new definitions without creating any new objects. For more information, see the 'How to share catalog updates' section below.

UDAs, options, views, pour units

Desription

User-defined attribute (UDA) definitions

When a model is created, the user-defined attribute definitions are read from the objects.inp files and the definitions are stored to the environment.db database. Modified and added new attribute definitions are shared incrementally.

New attribute definitions are added to the database automatically when the model is opened. If the current objects.inp file has a different definition than the environment.db, it is possible to take changes to use by clicking File > Diagnose & repair > Diagnose and change attribute definitions.

If the objects.inp file is in the model folder, it is shared as a file and it overrides the local objects.inp file when you read in.

Options

When a model is created, the options are read from the options.ini files and the model-specific options are stored to options_model.db and options_drawings.db databases.

Model-specific options can be modified using the Options and Advanced options dialog boxes. Modifications to model-specific options are shared incrementally.

  • Some of the options are of the type SYSTEM(ROLE). These options are read from the .ini files and are not shared. It is possible to change SYSTEM(ROLE) model option to MODEL(ROLE) option and the drawing option to DRAWINGS(ROLE) option. The options are then stored to the options_model.db or options_drawings.db databases in the model folder, and the value is shared incrementally.

  • Some of the options are of the type USER. These options are user-specific and they are not shared.

  • Some of the options are of the type SYSTEM. These options are user-specific and they are not shared. It is possible to change a SYSTEM option to a MODEL(SYSTEM) option. If you change a SYSTEM option to MODEL(SYSTEM), the changed value only works for the current model. These options are not shared.

Other important files in the model folder

The database ID range mapper file db.idrm and the library database ID range mapper file xslib.idrm are related to the handling of IDs. These files are needed, for example, to open drawings that have been created in single-user or multi-user modes.

The plotdev.bin file contains the print device definitions that you create in Printer Catalog (old printing). The file is shared when located in the model folder.

Note:

If your project has users that work in different offices and with different printers, you should not save any local changes to the plotdev.bin file in the model folder. Save the local changes in the XS FIRM folder instead.

View sharing

By default, views are not shared. Views are shared if they have a name, and the Share option in the View Properties dialog box is set to Shared.

Note that when you join a model, you get all the model views but changes to the views are not shared if the Share option is set to Not shared.

Pour unit information

Automatic assignments of objects to pour units are not shared. The Calculate pour units command has to be run in the local versions of the shared model to update the pour units.

When XS_CALCULATE_POUR_UNITS_ON_SHARING is set to FALSE (which is the default value), each user has to run the Calculate pour units command in their local version of the shared model to update the pour units.

If XS_CALCULATE_POUR_UNITS_ON_SHARING is set to TRUE, Tekla Structures automatically calculates and updates the pour units during writing out and reading in.

Manual assignments created by using the Add to pour unit and Remove from pour unit commands are shared.

Exclude files and folders from Tekla Model Sharing

By default, files and sub-folders in the model folder, and in firm and project folders, are shared when you share a model in Tekla Model Sharing. If you do not want to share all of the files or sub-folders, you can select to exclude some of them from sharing.

Note:

Tekla Model Sharing works only if the model is the same for all users. Tekla Structures takes care of model-specific data sharing. You can only exclude files that do not have an effect on the model. You cannot exclude any of the databases that are in the model folder, xslib.db1, for example.

Empty sub-folders under the model folder and some files are excluded automatically.

  1. On the File menu, click Sharing > Sharing settings.

    The Sharing settings dialog box opens.

  2. Click the Exclude button to see which files and folders are excluded from sharing, and to exclude more files or folders.

    Some files and folders are excluded automatically from sharing. These files and folders appear on the Excluded model folder files and directories list, and they cannot be removed from the list.

    1. If you want to exclude more folders or files, click the Directory or the File button.
    2. Select the folder or the file to be excluded.

      The excluded folders and files are added to the Excluded model folder files and directories list.

      If you exclude a folder, all its sub-folders and sub-files are also excluded from Tekla Model Sharing.

      You can exclude files in several ways. For example, if you have a file called TeklaStructures.bbb, and you use the following settings to exclude the files:
      Option Description
      (x.x) TeklaStructures.bbb is excluded from sharing.
      (x.*) All the files with TeklaStructures. are excluded from sharing.
      (*.x) All the files with .bbb are excluded from sharing.
      (*.*) All the files from that folder, but not from its sub-folders, are excluded from sharing.
    3. If you want to remove the added folders or files from the list of excluded files, click Remove.

      You cannot remove a folder or a file that has been excluded automatically.

  3. Click OK when you have finished selecting the excluded files.

How to share catalog updates

Sometimes you may need to update catalogs with new definitions, such as new profiles, and share the changes without creating any objects with the new definitions.

  1. Ensure that all users on the shared model write out their changes.
  2. Read in all the model changes.
  3. Update the needed catalogs.
  4. Create a new baseline.
  5. Ensure that all users join the created baseline.

    After users have joined the baseline:

    1. Ensure that users check that their settings for excluded files and folders are up-to-date in File > Sharing > Sharing settings > Exclude, or that they copy the FileSharing.ini file from the previous local version of the model in ..\TeklaStructuresModels\<model>\ModelSharing\Settings.
    2. Ensure that users remove their previous local versions of the model.

How to share Organizer data

By default, Organizer data is not shared. However, you can use the Organizer import and export with Tekla Model Sharing to share Organizer changes.

  1. Select a user who is responsible for the Organizer data. This is User A.
  2. User A creates the Organizer data and exports the data to a model subfolder.

    Note that the selected folder cannot be the default ProjectOrganizer folder.

  3. User A writes out.
  4. User B reads in and notices that there is new data available.
  5. User B opens Organizer, synchronizes, and imports the data that User A has exported by using the import and replace option. User B synchronizes Organizer again.

    The data appears as new in Organizer.

How different object types work in shared models

When several users modify the model at the same time in Tekla Model Sharing, conflicts may occur.

In general, all object types work similarly in Tekla Model Sharing. When you read in, the changes in the incoming packet override your local changes to the same object. In other words, if several users modify the same object, the user who first writes out the changes to the sharing service wins in conflicts.

Before you start to share models, agree on common ways of working. For example, you can agree that users work on different areas of the model.

Object / Property Description
Model objects

A shared modification to an object property overrides any other object property modification.

For example, one user modifies a beam profile and writes out. Another user has modified the material of the same beam and reads in. The user who modified the beam material loses the changes, because the shared changes override the local changes to the same object.

Family numbering

Check the family numbering settings.

Family numbering settings are shared but cannot be incrementally updated. We recommend that one user first reads in all the packets, makes the updates and then shares the settings by writing them out. If the user needs to read in before writing out, it is important to check that the settings are as they were before starting to share them.

Give start numbers in wide ranges so that you do not run out of numbers within a numbering series, and that any numbering series does not overlap with another.

We recommend you to use the Number series of selected objects command on the Drawings & reports tab when numbering.

Grids

If there is a conflict in sharing grids, grids are recreated using the original values that have been set in the grid properties. Any manually added grid lines are lost.

For example, when two users modify a grid by adding extra grid lines and write out, the added grid lines disappear from the model when they read in.

Catalogs

Check the catalogs so that they include all the needed definitions.

Starting from Tekla Structures 2018, the shape geometry files that are in .xml format are automatically converted to .tez format in shared models.

User-defined attributes (UDAs)

A shared change to a user-defined attribute (UDA) overrides changes to the same UDA only.

For example, a change in the Comment UDA overrides a change to the Comment UDA but not to the Shorten UDA.

A shared change to a part does not override UDA changes and vice versa.

Part and the related component

A shared change to a part does not override component changes and vice versa.

Custom components

If a user deletes a custom component from the Applications & components catalog in the local version of the shared model, reading in causes an instance of the custom component to appear in the model even if the component was not used in the model.

You cannot edit the component instance in the model. If you need to edit the component, explode it first.

Drawings

There can be duplicate drawings from the same part.

For example, two users create drawings from the same part when they are working on their local versions of the shared model. When both users write out their changes, two drawings appear in Document manager. Tekla Structures does not delete either of the drawings, and it does not merge the changes from the drawings. You need to visually check the drawings and decide which drawing to delete, or to use drawing locks to prevent other users modifying the drawings.

Pours

Agree whether pour management will be used in the model and set XS_ENABLE_POUR_MANAGEMENT accordingly.

If pour management is enabled in the model, do not disable it using XS_ENABLE_POUR_MANAGEMENT, especially in the middle of the project. This may cause problems if you have drawings containing pour objects, and if you are sharing your model. The pour objects and pour breaks in the model and in the drawings may get invalid, and you may lose all pour-related modeling work.

Automatic assignments of objects to pour units are not shared. The Calculate pour units command has to be run to update the pour units.

  • If XS_CALCULATE_POUR_UNITS_ON_SHARING is set to FALSE (which is the default value), each user has to run the Calculate pour units command in their local version of the shared model when they need up-to-date pour unit information.

    For example, user 1 moves a reinforcing bar so that it touches a pour object, runs the Calculate pour units command to add the bar to the pour unit, and writes out. When user 2 reads in, user 2 sees that the reinforcing bar has been moved, but the bar has not been added to the pour unit.

  • If XS_CALCULATE_POUR_UNITS_ON_SHARING is set to TRUE, Tekla Structures automatically calculates and updates the pour units during writing out and reading in.

Manual assignments, and other modifications to pour objects and to the objects attached to the pour objects (such as changes to geometry or location), are shared. A shared manual change in pour unit assignment overrides a local change.

For example, user 1 adds an embed to a pour unit by using the Add to pour unit command, and writes out. User 2 has added the same embed to another pour unit by using the Add to pour unit command. When user 2 reads in, user 2 sees that the embed has been added to the pour unit user 1 added it to.

Standard files for numbering setup

Standard files for numbering setup are not loaded automatically when you read in. If you want to take them in to use, you need to reload them after reading in.

Warning:

If an object deletion has been written out to the sharing service, the object will be deleted in your model when you read in. This happens regardless of whether you have modified the object before reading in. Deleted objects remain deleted if the deletion has been shared.

Deleted objects are not visualized when you read in.

How property files in the XS_FIRM and the XS_PROJECT folders are shared

You can store property files in user-defined sub-folders under the firm or project folders. The property files are copied and shared in Tekla Model Sharing in two situations: when you start sharing a model, or when you have a shared model open and click the Copy files button in the Sharing settings dialog box.

Property files are copied and shared from the following folders:

  1. The \attributes folder under the model folder.

  2. The user-defined sub-folders under the XS_PROJECT folder.

    If the XS_PROJECT folder is empty, Tekla Structures skips it when copying files.

  3. The user-defined sub-folders under the XS_FIRM folder.

    If the XS_FIRM folder is empty, Tekla Structures skips it when copying files.

  4. The sub-folders of the environment folder.

The folders are searched in the order they are listed above. When Tekla Structures finds the first corresponding file, that file is selected. Other corresponding files are ignored, and the file names are stored in the error log.

Note that if the following folders are immediate sub-folders of project or firm folders, Tekla Structures does not read property files from the folders:

  • ProjectOrganizerData

    • ProjectOrganizerData\DefaultCategoryTrees

    • ProjectOrganizerData\PropertyTemplates

    • ProjectOrganizerData\ExcelTemplates

  • AdditionalPSets

  • macros

    • macros\drawings

    • macros\modeling

  • Drawing Details

  • CustomInquiry

  • PropertyRepository\Templates

  • symbols

  • template

    • template\mark

    • template\settings

    • template\tooltips

  • profil

    • profil\ShapeGeometries

    • profil\Shapes

Was this helpful?
Previous
Next