1           Preface

The data database needs to be synchronised in the following two situations.

         The local procella or O-QIS procella logging station have a bad connection to the central database.

         It is important to apply and store the test plan of each measuring station separately in the central database in order that several stations are able to measure characteristics simultaneously without multiplying the test plans in the central database.

Bad network connection to the central database

Some logging stations might have a bad connection to the network. This is either due to a separate production network or due to a mobile connection (e.g. WIFI connection near welding installations or the like). Use a database synchronisation to minimise the data the local station accesses from the central database. The user applies local copies of the test plan at the procella logging station and stores the information in a local database.

How to avoid the multiplication of test plans in the central database

The task is as follows: Provide the same test plans to several logging stations so that they can be applied simultaneously but store the information in a single data database. In practice, users often multiply the test plans to solve the problem. There is thus one test plan available for each logging station. However, you have to combine all these data sets subsequently for a comprehensive evaluation. Please consider that any data compression you perform to store the results (summary benchmark) takes into account each individual test plan and might thus lead to a misinterpretation of available characteristics (depending on your approach).

You can avoid all these difficulties by synchronising the database. The logging stations use an own local database to apply and store local test plan copies. By synchronising these locally stored data, the system considers them to be a single test plan.

You needed a Q-DBM licence to use the database synchronisation in previous Q-DAS software versions. Since version 12, however, the database synchronisation has been provided by default and is free of charge.

This document provides you with information about the application and some obligatory configuration notes. In case any errors occur because you did not take these notes into account, you will need fee-based support, sometimes even an on-site appointment.

2           Installation scenarios and basic settings

The following aspects apply when you synchronise a database.

         A server-client system is always assumed for products evaluating data such as qs-STAT, solara.MP, destra or the M-QIS Reporting System.

         You HAVE to enable the Use database as server for test planning option for the central database under File | Configuration | Databases | Options | Administration | Database type.

         procella installations are stand-alone, local installations having an own configuration/licence database, text database and data database.

         You must NOT enable the Use database as server for test planning option for local databases.

         Depending on the amount of data incurred and the archiving concept you use, we recommend you apply a MS SQL or Oracle database as central databases.

         The enabled K-fields in the central and local databases MUST be the same. When the system checks the table and finds out that the tables contain a different number of fields, it cancels the synchronisation process.

         The GUID (globally unique identifier) for header data (GUID of parts and characteristics K1997/K2997) and values (GUID applies K0097) MUST be enabled in the central and local databases. Since version 12, the part and characteristic GUID is enabled by default. You cannot reset the GUID options after saving the settings.

         The system uses the part, characteristic and value GUID to search the central database for measured values. Only new values are added.

         The synchronisation stops immediately when there is a test plan without any part or characteristic GUID stored in the central or local database.

2.1     How to activate GUIDs subsequently

In case you activate the part/characteristic GUID and the value GUID subsequently for available databases, you have to start a basic takeover of these GUIDs.

Since you need to activate the change log temporarily to take over the GUIDs, we recommend you attend a fee-based workshop offered by the Q-DAS project team. Please contact a responsible person of the Q-DAS project team or send an email to info.qdas.mi@hexagon.com.

As an alternative, you may transfer these GUIDs manually for each test plan. Load the respective test plans after activating the part/characteristic/value GUID and you may close them again without saving them. The system adds the part/characteristic/value GUIDs to the database while loading the test plans. Depending on the amount of data involved, the first time you create GUIDs for already available measured values might take a lot of time; sometimes it takes days.

2.2     GUIDs for subgroups

In case you work with fixed subgroup sizes, K-fields 0080 and 0081 (subgroup ID and position in the subgroup) MUST be enabled in the central and local databases. You also have to activate the Rearrange subgroups (K0080, K0081) option under File | Configuration | General setting | General settings 2 in local and serve-client products (procella, qs-STAT, ).

3           How the synchronisation works

A central location assigns the test plan to a logging station. The following chapters describe all settings you need. This chapter, however, is to illustrate the basic concept of data synchronisation and explains the single internal steps.

This is what happens when you start the first synchronisation at the local procella logging station.

         The system synchronises the station GUID of the local database to check whether it is only available once in the central database (station table).

         The system synchronises the tables and fields of the local and central data database to check whether they are identical.

         All test plans assigned to this logging station are stored as a copy in the local database. Test plans created in the local database are not transferred to the central database. It is generally not recommended to transfer them.

This is what happens when you start the synchronisation again.

         The system synchronises the station GUID of the local database and the name of the local logging station to check whether they are only available once in the central database.

         The system synchronises the tables and fields of the local and central data database to check whether they are identical.

         All new test plans assigned to this logging station are stored as a copy in the local database.

         Most changes in the configuration of test plans available in the central database now also apply to the already available test plans in the local database. There is not synchronisation of central databases measured values with the ones of the local database.

Interfaces for data recording via RS232 and the number of decimal places locally adjusted after connecting new measuring equipment are not synchronised either.

         The system searches for any locally available measured values in the central database based on their value GUID. In case the central database does not contain them yet, the system transfers them.

In case the change log is activated in the local database, the system also transfers the changes in measured values. Changes in test plan configurations are not transferred from the local to the central database.

         Depending on the system settings of the local database synchronisation, only the last x measured values are kept locally. Measured values older than that are deleted from the local database.

         Test plans that are indicated to be deleted from this workstation in the central database are deleted from the local database as soon as the last measured values are transferred.

4           Rules to follow when applying the database synchronisation

It is crucial to accept some basic rules when using the database synchronisation. As a consequence of ignoring these rules, the synchronisation might no longer work at any of your test stations. Fixing such an error requires the support of our customer service or project team and is subject to a fee-based TeamViewer meeting. If the matter is serious, you will even need their support on site.

NEVER copy a QSSTAT2000.ini or one of the product INIs (%Product%.INI since version 12) from a logging station onto any other logging station.

When you start a Q-DAS application for the first time, the system creates a station GUID in the QSSTAT2000.ini or in the respective product INI (since version 12) file. The station GUID and the name of the logging station help the system assign test plans in the central data database. Applying the same station INI twice leads to an erroneous synchronisation or even stops the synchronisation process.

In case you really need to copy an *.ini file, delete the station GUID entry from the %Product%.ini file first.

NEVER copy a station GUID stored in the data database from one logging station onto any other one.

Each logging station that connects to the data database for the first time is registered to use this database. The system writes the respective entries in the Station table.

In case you really need to copy the data database, you first have to remove the data set of the respective logging station completely from the Station table.

NEVER copy a local data database from one logging station onto any other.

Each data database that connects to a Q-DAS application for the first time is provided with a unique database identified in the Zyklus table.

In case you really need to copy a local database, delete the unique database identifier (ZYTXT column) from the database first.

NEVER save a test plan from the central or any local databases as DFQ files and copy it back as a new or modified test plan into the data database.

The test plan synchronisation is based on the part GUID (K1097). If the same part GUID is available twice in the data database, the synchronisation will stop.

In practice, test plans are often saved as files and e.g. serve as templates for new test plans. You modify them and save them as a new data set to the database. Even though you store an old test plan as a new data set, the system still uses the same part ID for the old and the new one and you have the same GUID twice.

In case you really need copies of the test plans, we recommend you make a copy by using the Copy test plan database option since this option creates a new GUID for copied test plans. However, if you have to generate a DFQ file first, we recommend you use the Extended save options to delete the part GUID before you save the file.

5           Special central database settings

Consider three settings in the central database:

         Enable the Use database as server for test planning option (File | Configuration | Databases | Database type).

         The part and characteristic GUID and the value GUID have to be enabled (File | Configuration | Databases | Additional data).

         The change log shall be deactivated. An activated change log in the central database has a negative impact on performance (File | Configuration | Databases | Database type).

6           Special local database settings

Consider three settings in the local database:

         Do NOT enable the Use database as server for test planning option (File | Configuration | Databases | Database type).

         The part and characteristic GUID have to be enabled (File | Configuration | Databases | Additional data).

         The change log MUST be activated. This option records any changes made to test plans or measured values. An activated change log has a positive impact on the performance of the synchronisation (File | Configuration | Databases | Database type).

         Initially, the local database MUST NOT contain any test plans!

7           Database connections

In case you did not establish any database connections yet, you can create and adjust them for the local and central database under File | Configuration | Databases.

Q-DAS database

Defines the connection to the local database.

Central database connection

This is the connection to the central database. You may establish the connection to the central database manually via database synchronisation or synchronise the database at regular intervals.

How to enregister the computer in the central database

In order that local computers are able to apply test plans stored in the central database, you have to enregister this computer once in the central database. Take the following steps.

         Select File | Configuration | Databases and select the connection to the central database under
Q-DAS database.

         Confirm the settings by clicking OK to enregister the logging station in the central data database. It is now listed in the overview of stations and you may assign test plans from the central database to this station.

         Reset the local database to the previous connection. Reset the entry under Q-DAS database to the local database.

8           Assigning test plans to local stations

When you enabled the Use database as server for test planning option for the central database and you activated the SPC test planning menu option in the ribbon, the function assigning test plans to local logging stations will be available to you.

A window opens that is similar to the Read from database one. However, it lists the single logging stations already enregistered in the central database instead of characteristics. To assign a test plan to a logging station, you drag and drop the test plan to the name of the logging station.

Test plans assigned to logging stations may not be deleted. If you try to delete it, the following error message will appear.

You have to remove the allocation to delete a test plan.

8.1     How to delete test plans from the local logging station

When you want to delete the allocation of a test plan to a local station, you highlight the test plan for the respective logging station and tap <DEL> to mark it for deletion. A confirmation prompt opens asking you whether you are sure that you want to mark the test plan for deletion.

A test plan marked for deletion is indicated as follows.

Marked for deletion means that the system checks whether all measured values are transferred from this logging station to the central database during the next synchronisation. After this check is completed, the system deletes the test plan from the local database and from the test planning tasks of this workstation.

If you delete a test plan that is already marked for deletion once again by tapping <DEL>, the confirmation prompt opens once again. If you confirm this prompt by clicking OK, the test plan will be deleted completely from the list of this logging station.

If the respective copy of the test plan is still available at the local logging station, measured values recorded in the meantime will no longer be transferred to the central database.

9           Configuring SPC test planning

Use the Station summary menu option (File | Configuration | Databases | Administration | Database type) to assign a description to a logging station.

Confirm each input by clicking .

Use the Sort option to change the sequence of station names.

The displayed SPC test planning changes accordingly.

10      Database synchronisation settings

Use this dialogue box to adjust the database synchronisation settings for local logging stations. The configuration you adjust is saved to the local value database (and not to the configuration database) and transferred to the station summary of the central database.

Stat/End time

Adjust the synchronisation period. Use these settings to bring the synchronisation to a halt to back-up the central database.

Interval

Specify the intervals for an automated synchronisation.

Repeat point in time

When a synchronisation stops, the system tries to synchronise the data again at the specified time. When you set 0, a cancelled synchronisation will not start again.

Compress database after

The system compresses the local (Access) database at the adjusted intervals.

Database compacted at

The system compresses the local (Access) database on the specified day of the week.

Max. no. of values in DB

Depending on the respective characteristic, the system keeps the specified number of measured values in the local database. Set 0 to keep all values locally. The system deletes all values older than the specified value after the corresponding characteristic has been synchronised successfully.

Max. size log file in KB

The system creates a log file (SYNCHRON_DB.LOG) with the specified size in the installation path of the \TEMP directory.

Start without asking

The synchronisation always starts at specified intervals. The user is not able to cancel it.

Synchronise directly

The synchronisation always starts when you open the software.

10.1 Reasons why the synchronisation does not start

There are different reasons why the synchronisation does not start.

         An error occurred while connecting to the database.

         The test plan is currently open.

11      Starting the database synchronisation manually

Use the option shown below to start the database synchronisation manually. We recommend you keep the manual database synchronisation during the implementation and test phase and adjust automated cycles later on.

12      Recommendation

In case you open test plans locally, e.g. by using the Part selection database dialogue box, you may also specify additional data in this dialogue box. If the same test plan is available at several logging stations, we recommend you add a station ID to get an overview of the allocated logging stations.

When you apply the subgroup ID (K0080 / K0081) please consider the composition of the ID. The %Product%.ini defines that it includes date, time and a K-field.

K0080_ID=DATE,TIME,K1206