Where does data come from when you open a BIM file?

  • Makale

By default, when you open the .bim file after closing it, the data comes back. Did you ever wonder where this data comes from? It depends on a number of factors. Let’s explore.

Before we begin, I want you to keep a very important point in mind. The metadata in the BIM file is always more important than the data in the workspace database. If there is ever any conflict, the BIM file will always win. You can be assured that the file saved to disk is always the canonical source for metadata in your model.

Now, to the data loading behaviour.

Default behaviour – when there is a user settings file

As I have mentioned before, there is a hidden user settings file called Model.bim_<username>.settings. This file is automatically created whenever you open a BIM file for the first time. For the most part, you don’t need to know or care that this file exists. However, it does have some magical functions. The most important magical function is that if it is present, it decides the location from which to fetch the data on open.

First – the workspace database is checked. The designer uses the settings file to determine the name of the workspace database. If the workspace database is in memory, great. If the workspace database is detached, it’s reattached. If something goes bad during re-attachment, or if the workspace database no longer exists, we create a new one.

Now that we have a workspace database, we check the integrity of the database. If the metadata for the workspace database matches the metadata in the BIM file, you start editing and everything is fine.

If there is a metadata mismatch, we go to the next check. We check to see if the user has previously configured the project to take backups. If the user is taking a backup, and there is an ABF in the folder with the BIM file, we go ahead and restore the ABF for the model. Now, we check the integrity of the database as before. If the metadata for the workspace database matches the metadata in the BIM file, you start editing and everything is fine.

If you get to this point and you’re not editing yet, we now know that neither the original workspace database nor the backup ABF have the correct metadata for the model. We then apply the XMLA in the BIM file to the workspace database, and you begin editing. At this point, you may or may not have data for your model.

Special case – when there is no user settings file

There are a few ways to get yourself into a situation when there is no user settings file:

  • You got your tabular project from source control. The user settings file is not checked in.
  • You copied the tabular project from another user. That user’s name doesn’t match your name.
  • You manually deleted the user settings file. This is generally not recommended but comes in handy sometimes, see my working with backups post for a scenario (quick change to model where you don’t have source and need to see data). 

When there is no user settings file available, we will always create a new workspace database for you on open of the BIM file. Initially, this is an empty database. If you are working on a local workspace database server, and there is an ABF file present in the folder where the BIM file lives, we will restore it to the workspace DB server. We will check the integrity of the database, and if the metadata matches the metadata for the BIM file, you can begin editing. Otherwise, we apply the XMLA in the BIM file to the workspace database, and then you can edit. As above, you may or may not have data.

Example – loading the data after closing without save

Now that I have explained the behaviour, let’s take a look at an example. When you edit, every change you make to the model alters the workspace database. Closing or saving the model changes the state of the BIM file, but does not change the state of the workspace database. If you close without saving, you can get into a state where your BIM file gets out of sync with the workspace database, so on next open we have to do a bit of data recovery.

Say you create a new tabular project using the default settings (detach with no backup). You create a model with several tables (say tables 1 through N), pulling data into all the tables. Save the BIM file. Delete a table (say table 1), then close the project without saving. At this point, the workspace database is detached from memory, and the workspace database contains and metadata and data for tables 2 through N, as this was the last edit state. Now reopen your project. The workspace database is attached. The metadata is checked, and it is inconsistent with the BIM file. The user settings says not to check for an ABF, so we go straight to applying the XMLA in the BIM file to the workspace database. The result is a workspace database that has metadata for tables 1 through N, and data for tables 2 through N (since we had data for them in workspace database from the last edit).

This partially processed state is a surprising result for some people. This is the price you pay for not having a data backup. If you would like to avoid getting into a partially processed state, take backups on save. This backup can then be restored to the server and you can continue working as if nothing happened on close without save. There are penalties to taking backups, as I explained in the backups post (link it one more time), but taking a backup is really helpful for recovery purposes on load.