---
title: "Configuration - New"
canonical: "https://servicedesk.maxgeo.com/space/LogChief/1275330616/Configuration%20-%20New"
format: markdown
---
> Macro (toc)
Configurations are a logical and physical grouping of logging data. Each Configuration created in LogChief will have a database created with the same name (a Configuration called 'maxgeo_Demo_Configuration' will have a corresponding database created called 'maxgeo_Demo_Configuration' on the same SQL Server instance as the LogChiefSystem database).
Creating a Configuration involves taking a copy of an existing MDS (maxgeo Data Schema) Database and modifying it for Logging purposes (creating a Configuration database). The resulting 2 databases are designed to synchronise data back and forth, so need to share a similar structure (tables, columns, constraints, keys, etc.).
*Editing your Configuration will delete your logged data! The data will only be erased if you complete the Edit Configuration Wizard and click 'Save' . If the Configuration Database is acting as the main Database, this will mean losing all data logged in the Database! Because of this, we recommend making no modifications to the Configuration.*
Configurations include:
- Connection to the Main Storage Database;
- Selecting Project & DataSet tables
- Mapping table relationships (i.e. Parent-Child mappings)
- Alterations to the selected tables' schema
- Mapping LogChief's required fields
- Configuration of Library Tables
- Synchronisation Settings and Order;
***Note****: Creating, modifying or deleting a configuration will not affect the template MDS database in any way.*
***Note:**** In order to create or edit a Configuration, the user must have administrative access rights to the MDS. This is not required for importing Configurations; for importing and duplicating a Configuration, the user only requires sufficient user permissions on the Local SQL Server.*
## **New Configuration**
Before logging data into LogChief, a LogChief configuration needs to be created. Creating a Configuration will replicate the entire MDS database structure into the Configuration database, as well as populate all Library and System tables. Although the Standard 'maxgeo_Demo_Configuration' has already been created and will be available to use, if for any reason a new configuration is required, the steps in the New Configuration section of this User Guide will assist you. Any modifications to the existing Configuration should be made by **Editing** the Configuration.
To create a new Configuration, click on the *Configurations > New* menu item through the icon in the main window of LogChief. This will load the Configuration Wizard.
## **Database Connection**
A name needs to be assigned for the LogChief Configuration. A database will also be created with the same name as the Configuration.
*Note: The LogChief Configuration database will be created on an SQL Server instance, the same SQL Server instance on which the LogChiefSystem database is stored.*
Enter a name for the configuration in the Configuration text box.
Create a connection to the database you want to log against by following these steps:
- Select the SQL Server Instance where the database is located
- Choose an authentication type, either Windows or SQL authentication
- Enter the username and password if you are using SQL Server authentication
- Select the database you want to log against from the Database list
## **Table Selection**
In LogChief, everything happens through Mapping. Mapping is the closest entity which binds tables and define their relationships.
Before a user creates any mapping, LogChief creates one mapping called "Default Mapping". This mapping is based on **Project** and **DataSet** table-types. LogChief automatically, depending on search patterns, adds tables to the Default Mapping. A User cannot delete this Defaul Mapping but can change the tables and must be aware that changes can damage LogChief processes. DataSet filtering works on this mapping.
A User can see the details of this mapping using the configuration wizard window shown below. Values in these tables are refreshed by clicking 'Refresh Libraries' (see [Refresh Libraries ](#page100)section), then the tables can be reselected.
On this screen, user is able to create custom table mappings and select all tables required for logging. Although creating a Configuration will replicate the entire MDS database into the Configuration database, LogChief will only allow you to log to tables that have been included in mappings.
The follow window below will then open:
## **Creating Table Mappings**
In this section, the Parent-Child mappings between tables are created in order to define the way data is logged through LogChief. These mappings represent a hierarchical relationship between tables in the database and will also control how the tables are viewed in the LogChief Profiles. The most basic Parent-Child relationship is outlined below:
*Example of a basic Parent-Child relationship required for downhole logging. A Collar is defined in the Parent table and then data is logged to that collar in the Child tables. The logging workflow is defined by the hierarchy such that the parent table must be populated before any child tables can be logged to (much the same as hierarchical logging on the column level - see in subtopic** Logging Window Setup)*
***Note -**** User must not map tables with relationship between them on the same level. E.g . You should not ma p tblDHColl & tblDHGeology a t same level in any mapping . They will always have Pa rent/Child relationship*
### **Creating a New Parent-Child Mapping:**
1. Click on the 'Add Mapping' button and enter a name for the new mapping in the box under the 'Mapping Name' header. The name 'Mapping Example' has been used in the example below.
2. Select the Parent table for the Mapping by dragging the table from the table list on the left hand side and placing it under the Parent table object in the centre of the window. This list contains an entire list of tables (minus tables beginning with dbo.tblLIB which are reserved for Library tables) derived from the main database to which the connection in '[Database Connection' ](#page13)was set).
*Note that only one table can be selected as a Parent for any given mapping.*
3. Select the tables which will act as Child tables to the Parent defined in the previous section by the same process of dragging and dropping tables from the list on the left. As many tables as required can be chosen as Child Tables.
4. Define the Table type of the tables selected in the mapping through the dropdown menus in the 'Table Type' column (see below). The list contains some standard Table Types as well as the generic 'Parent' and 'Child' types. As a general rule, if the table begins with 'dbo.tblDH' then it is likely to be a Downhole type (except for the Sample tables which have their own types and DHSurv which is a CollarRelated type); if you are unsure, simply select either Parent or Child types.
5. Only Collar, Surface Sample and Parent can be selected as Parent Type.
*Note: if the Parent table is given the type 'Parent' then all the Child tables must be given the type 'Child'*
The example below shows the definition of the basic Collar-Downhole relationship. Other Downhole tables may be added to the mapping as required for logging.
6. Once the mapping is completed click on the 'Accept Mapping' button on the right hand side of the window to save the mapping.
### **Edit a Mapping:**
Select a Mapping from the dropdown list (containing all previously saved mappings) under *Mapping Name*, modify the tables in the Parent or Child categories and select 'Accept Mapping'; to confirm* *the modifications.
### **Remove a Mapping:**
Select a Mapping from the dropdown list (containing all previously saved mappings) under *Mapping Name* and click on the 'Remove Mapping' button on the right hand side of the window.
### **Multiple Order Mappings:**
Several Orders of Parent-Child Mappings can be defined to represent the various levels of a hierarchy.
*Note: Only one Parent-Child mapping may be viewed through a single profile, meaning that if a second or third order mapping is created the tables will have to be logged to under a different profile.*
The example below shows the table hierarchy for the Face mapping and the relevant Parent-Child relationships which have been setup to accommodate this structure:
*Example of a proposed* *tiered relationship. In the* *1**st* *order relationship, Face ID is the parent to both Scanline ID and Point ID. In the 2**nd **order relationship, the Scanline* *and Points are now acting as parents to Geology and Structure Tables.*
To accommodate the above Face mapping hierarchical structure three Parent-Child mappings will be required: 1. where Face ID is parent, 2. where Scanline ID is parent, and 3. where Point ID is parent. The Scanline and Point ID tables will exist in two Mappings as both Child and Parent. These mappings in the maxgeo_Demo_Configuration are shown in the screenshots below:
2nd order Mapping with Scanline ID as Parent:
2nd order Mapping with Point ID as Parent:
### **View for Data Logging**
User can also map a View in Mappings. View must follow the following guidelines though It must be a **updatable** view; **triggers** for **insert, update** and **delete** the data from corresponding tables It should not have **inner join **Joins / Where Clause must have same series of columns. This is very important for Synchronisation.
E.g. In the following situations, Synchronisation fails because of **Instead Update Trigger.** The keys are different in joins.
```sql
UPDATE S
SET DataSet = I.DataSet, SampleID = I.SampleID
,Site_ID = I.Site_ID, Line_ID = I.Line_ID
,Depth_From= I.Depth_From, Depth_To= I.Depth_To
,Sample_Type = I.Sample_Type, Sample_Method = I.Sample_Method
FROM
tblFSSamp S
INNER JOIN INSERTED I ON S.DataSet = I.DataSet AND S.SampleID = I.
SampleID
WHERE I.Lith1_Code IS NOT null;
UPDATE G
SET DataSet = I.DataSet, Site_ID = I.Site_ID, Line_ID = I.Line_ID
,Depth_From = I.Depth_From, Depth_To = I.Depth_To
,Priority = I.Priority, Lith_Plot = I.Lith_Plot
,Lith1_Code = I.Lith1_Code, Lith1_Texture = I.Lith1_Texture
FROM
tblFSGeology G
INNER JOIN INSERTED I ON G.DataSet = I.DataSet AND
G.Line_ID = I.Line_ID AND G.Site_ID = I.Site_ID AND
G.Depth_From = I.Depth_From AND G.[Priority = I.
Priority
WHERE I.Lith1_Code IS NOT null;
```
In the above scenario, whatever set of columns you make as Primary Key, the synchronisation will fail because after DataSet, different columns exist in both joined conditions.
**Select Primary Key**
User must have a very good knowledge of Primary Keys of all tables in the View because th user has to select the Primary Keys for View that must match with all tables in the View; otherwise, synchronisation will fail.
**Create Libraries**
Need to select Libraries for View
**Import Configuration from Previous Versions & Builds**
In case when a user has imported the configuration from previous versions or builds prior to 3.1.2.2 and it has Views, the User must remove the view from the configuration and add it back. NOTE: You will loose the custom layouts in this case.
Once all required mappings are saved then click '**Next >**' to progress to the Table Setup section of the Configuration Wizard.
**Remove Table**
User can remove a table from the mapping using "Remove Table" button. There is a process involved if you are planning to do so.
1. Select the table and click on "Remove Table" button
2. Save the mapping using "Accept Mapping" button
3. Click on "Next" to go to next page. This is very important process. When you click on "Remove Table", LogChief will only mark the table as "Removed", it doesn't delete this table from the System. Going to next page will make sure that the table is removed from the system and all the references are cleared
4. Click on "Back" to go back to "Table Selection" page and continue with mappings
**Case Study -**
If you have added a database-view as a parent and want to replace that database-view with the table, which is a part of same database-view e.g.
tblVWCollEvent is a database-view which consist of **tblDHColl** & **tblDHEvent** tables. You have added this database-view as a parent in a mapping and now you want to replace the parent tblVWCollEvent with tblDHColl table
Please do the following steps for smooth transition
- Remove the tblVWCollEvent from the mapping using "Remove Button"
- This is very important step. You want to replace a Database-View with the Table which is used in same Database-View. Simply adding back tblDHColl here will not work because LogChief will not be able to remove the tblVWCollEvent database-view completely from LogChief-System database. Add any table, which is not part of any mapping in current configuration e.g. tblXXXXXX
- Save the mapping using "Accept Mapping" button
- Click "Next" and go to "Table Setup" page. By now, LogChief have removed tblVWCollEvent and all it's references form LogChief-System database including **tblDHColl** & **tblDHEvent**
- Click "Back" and come back to "Table Selection" page
- Select the same mapping from mapping drop-down
- Remove table tblXXXXXX from the mapping using "Remove Button"
- Add tblDHColl as parent. LogChief will treat tblDHColl as new table in the
- Configuration and redo reference check e.g. ForeignKeys, Constraints etc
- Save the mapping using "Accept Mapping" button
### **Table Setup**
The Table Setup page of the Configuration Wizard allows the user to customise the structure (schema) of the selected tables.
The table schemas are retrieved from the database and can be modified without having to modify the source database.
The example above loads all table settings from the MDS (maxgeo Data Schema) which the configuration is based on. This does not apply to the table Triggers which are loaded as-is from the MDS; however, they are not 'checked to be included' into the Configuration database by default. The user must go through each table's trigger group and check them if they want to include that trigger in the Configuration Database.
All options below will be applied to the Configuration database to be created.
**Include**
Exclude fields from the configuration by deselecting the Include option. The field will still be copied across to the Configuration database; however, the field will not be available for Logging data in LogChief.
*Note: Columns defined in the Database as 'Computed Columns' are, by default, NOT included. If they are required by the user, mak e sure to manually include these. They will also need to be made 'Allow Null' to operate properly in LogChief.*
**Default**
Define a default value for the field. This will be added to the list of table constraints in the Configuration database.
**Allow Null**
Control whether a field in the Configuration database allows null values. An error will be displayed on the Logging form if a record tries to insert a null value into a non-null field when a row is entered or the 'Save' button is pressed.
**Custom Validation**
Define validation rules for any field. These will be added as a 'Table Constraint' in Configuration database.
To build a validation rule, click on the Custom Validation cell for the field you want to add a rule to and then click on the '...' button within the cell to launch the Validation Rule Builder.
**Sync**
Control whether the data logged to the field in the Configuration database is synchronized to the MDS database when the 'Sync' functionality is used.
**Constraints and Triggers**
Control whether or not to include constraints and triggers in the logging database. All the MDS constraints are included by default. All the MDS table Triggers are included by default.
User can create new triggers here by right clicking on the Trigger option. User will have 3 choices:
Add Trigger, Edit Trigger and Remove Trigger.
Edit and Remove Trigger options only available to Custom Trigger (Triggers created using "New Trigger" option)
This option is not available for Views. User will only see Columns for the View.
### **Required Fields**
All tables which are intended to be logged to (all the tables selected in the 'Table Selection' screen in the Configuration Wizard) need key fields to be mapped for LogChief to function.
LogChief automatically tries to map necessary columns based on what it thinks the name of the column will be. This will not be done for tables chosen as a generic 'Parent' or 'Child' Table Type when creating the Table Mappings in the [Table Selection ](#page14)section. Any table that appears in more than one mapping (be it multi order where the table appears as both a Child and a Parent, or that it simply appears as a Child in multiple mappings) will appear under each of the mappings and the Required Fields must be completed for each occurrence.
The fields highlighted in yellow must be assigned a table column in order to progress to the next stage.
**Field Descriptions:**
The bold, expandable fields on the left hand side under the Table column are the saved Mappings under which the Parent and Child tables can be found.
The HeaderID (01, 02, 03, 04, 05) fields are the important link between Parent and Child tables, and will appear in the Logging view as dropdown headers to filter data on the screen. In the basic example of Collar-Downhole Logging, the collar table has one header, DataSet - whereas the Downhole tables will have a second header, Collar ID - under which data is logged. These fields should be part of the Primary Key of the Table.
The FieldID (01, 02) fields represent mandatory fields part of the Tables Primary Key configuration. It is only necessary to map the FieldID 01 field for any table. The FieldID 01 value for a Parent table will become the next HeaderID for the associated Child Tables (see Face/Scanline/Point mapping configuration example below).
If user maps FieldID 02, it will also act as next header for child.
Database Requirements for **Parent, Collar, Point Sample, General, Point Sample QC** and **Standard** table types
- All the HeaderID fields must have foreign keys and they must come from the same foreign key table.
- For other Table-Types, user can map any fields as per the header counts. They must have same SQL data type corresponding to the parent header. Other table types header fields don't need a foreign key.
***Note****: A table that is a Child in a 1**st** order mapping and a Parent in a 2**nd** order mapping will have the same Required Field Layout for both occurrences.*
*It is important to remember that the Child should always have one more HeaderID populated than the Parent has.*
The Example below outlines the Required Field Layout for the various Tables in the multi order Mapping described in the [Table Selection ](#page14)section.
1. 1st Order Parent - tblFaceHeader:
2. 1st Order Child - tblFacePointHeader and tblFaceScanlineHeader
*Note how the FaceID, which was the FieldID 01 in the Parent is now the HeaderID 02 in the Child Tables.*
3. 2nd Order Child - tblFaceScanline... Tables.
In this case the tblFaceScanlineHeader is the parent and has the same Required Field configuration as above.
*Note how the ScanlineID, which was the FieldID 01 in the Parent is now the HeaderID 03 in the Child Tables.*
In the first Parent of any Mapping hierarchy only one field should be assigned to the Header (in this case HeaderID 01) which is usually mapped to the field 'DataSet', although this can be any field taking its values from a Library or System table.
The headers will appear as follows in the Logging View and are used to filter the values to be logged:
1. 1st Order Parent
2. 1st Order Child / 2nd Order Parent
3. 2nd Order Child
**FieldID 02 Required Field**
**Mapping Required Fields**
To map a field, select the table in the left panel, click on the HeaderID or FieldID (cell) to map and select the appropriate database column from the dropdown.
Mandatory mappings (database primary keys) are displayed in Yellow. The mappings in the white cells are not mandatory, they do not prevent the user from creating a configuration. However the more columns that are mapped, the more LogChief is able to manipulate/display data.
**Mapping Special Fields**
**AutoIncrement Field (For all TableTypes)**
If this filed is mapped, LogChief will increase the value of the mapped column by one every time a user logs a new row using the Logging Screen. This field has to be a numeric field or the data that belongs to this field has to be numeric. *Please do not map HoleID or SampleID here. To increment HoleID or SampleID, there are separate functionalities available in LogChief. You may try** **[Predefined](#page156)** **[HoleID ](#page156)**or** **[Predefined SampleID ](#page157)**or** **[Increment HoleID / SampleID ](#page154)**options.*
**FieldPhoto Filed (For all TableTypes)**
This field works along with other settings. A User has to set the "**[Default Photo Path](#page188)**" on "**Tools -> Options..**" screen.
If everything is set, the User clicks on Field Photo button on Logging screen and selects the Photo(s). LogChief will set the corresponding column value for each row(s).
**DataSet (For Parent & Child Table-Types)**
This field will be used for Filtering the Logging screen if a table has the DataSet column; the first dropdown values are filtered by this field setting. If you select the **DataSet** field, you must select the same field in **Header 01**.
**Depth From & Depth To (For Parent & Child Table-Types)**
These fields will be used to control Interval Operations for Parent & Child Table-Types
**Start DateTime & End DateTime fields**
LogChief will set the value of Column Mapped as "Start DateTime" with the value of Column Mapped as "End DateTime" when a user creates a new row or copies an existing row.
The value of DateField_1 will be set to DateField_2 when user will create new row or copy existing row.
**Source ID & Secondary Source ID fields**
These fields will be used with Standard Table-Type
E.g. with Collar mapping, user can map "HoleID" column as "Source ID" field. This mapping will be used when you will be importing data from database. See the screens below.
**"Source ID" field will also be used for Synchronization, when you select "Synch By ID" option.**
**Verified Field**
This field is used to identify table(s) for which ["Record Verification" ](#page179)required. User can map any data column with bit data type, LogChief will consider that column for "Record Verification" and set it's value during the process.
**Priority Field**
This field is used for overlapping intervals check. LogChief will use this filed and allow user to log same interval again with different Priority values. This field is available for Downhole
### **Required Fields - Example**
The following is a complete set of mapped Requiredfields.
### **Library Tables**
Every table selected by the user in the '[Table Selection](#page39)' section in the LogChief configuration wizard needs to have its foreign keys reviewed here.
On LogChief's logging screen when the user logs to a foreign key field, instead of entering the foreign key value, a combo box will appear. This combo box will contain values from the primary key table. This is set up to aid the user in selecting a foreign key field.
In the below example, tblDHCollar.Hole_Status is a foreign key which links to tblLIBHoleStatus. The Code mapping column has been set to tblLIBHoleStatus.Code and the Description mapping column been set to dboDHColl.Description.
How this will appear on the Logging form is as follows:
And if logging in the Grid Layout (E.g. Orig_Grid_ID):
Here we are logging values to the Collar (or tblDHColl as it exists in the Configuration database).
In Hole_Type field (tblDHColl.Hole_Status) a dropdown box is displayed. This dropdown box contains all the values from Library table tblLIBHoleStatus for the fields Code (tblLIBHoleStatus.Code) and Description (tblLIBHoleStatus.Description). The user can then select a value from this list to populate the field.
For Orig_Grid_ID field, the dropdown box contains all the values from Library table tblSYSSSRSCoordinatesSystems.
User can search for table name in the list of tables for "Library Table" column
### **Synchronise Settings**
There are synchronisation settings for individual fields in the Configuration Wizard. The synchronisation settings in this Profile Wizard provide additional control over the Synchronisation.
**Synchronise new and modified records only**
If checked will only update records which are new or have been edited. If unchecked will update all records to the database.
**Check for database schema changes**
Will compare LogChief's database schema with the actual database schema to check they match before synchronising.
**Synchronisation Order**
Synchronisation Order is set by LogChief itself, user can't modify the order. This order is based on the Table-Types and then the ForeignKey Hierarchy. e.g.
LogChief first collect all the tables mapped as following TableTypes
Collar
Parent
Point Sample
Downhole Sample
and then go through the database and find out the hierarchy of these tables using ForeignKeys and rearrange them.
This order will be applicable for **"Synchronise new and modify records only"** in both the options ( [Synch ](#page171)& [Advanced Synch](#page172))
**Include**
Whether to synchronise data for a particular table in the Configuration database to the MDS database. By default all tables will be included and user can't change this setting. This will be used when user uses direct synchronisation option (**Synchronise new and modified records only)**
**Delete Data**
Whether to delete data from the table in the Configuration database after it's been synchronised to the MDS database (provided the synchronisation was successful). This will be for **Synchronise new and modified records only**.
### **Summary**
This Summary screen displays all settings defined in the Configuration wizard. These settings represent SQL Server scripts which will be used to create the Configuration database.
'Save' and 'Print' buttons are available at the bottom of the screen if you want to make a copy of the Configuration settings.
Click 'Save' to start the Configuration creation process. This process may take a couple minutes.
