Treedb has no user operated ‘Save’ functions. Whatever is entered is automatically saved. A file is thus saved and date stamped accordingly automatically upon exit. Thus prompting the question “What happens if I make a mistake?” The answer is “Don’t make mistakes!” And when you do your only recourse is to reload your back-up. "No back-up! I've lost half a day's work!" Your fault then. This tends to keep your mind focused on the task in hand!

A database will comprise either two or three matched (common time and date stamps) files. With common file name and with (always) file extensions .dat and .idx plus (optionally) .blb.

These files ‘communicate’ with one another whenever they are accessed by the exe that is designed to open them for purposes of retrieving data. Mixing files originated at different times will not work and may even create havoc on the computer. The rule is, NEVER copy an idx file for example over that originally married to a different dat.file.

All Mistral Treedb db files follow a similar name pattern. All files are named with a leading ‘X’ character, followed by a three letter code defining the db content type as listed below, followed by an underscore and finally a three character (mixed letters and figures if desired) associating the file set with the owner or originator of the data contained. This three character code is called the ‘Legacy Code’.

For example:- xvlv_UDR.dat, xvlv_UDR.idx and xvlv_UDR.blb is a matched three file database set containing Expansion Valve selection data and parameters for United Refrigeration.

Another example:- xcol_SEA.dat, xcol_SEA.idx and xcol_SEA.blb is a matched three file database set containing Unit Cooler selection data and parameters for GEA Searle.

Back to top
The complete list of file name stems and their functions are as follows:-

Databases are given a ‘Type Key’. Type keys are integers from 1 to 8.

The Type Key defines the function of the database.

Each database contains Nodes which are named to define their function. In many cases the names for nodes are proprietary, are read by the accessing program executable and therefore cannot be changed.

The structure of the database is however quite flexible and ‘multi-relational’. An almost infinite number of ‘levels’ of data can be optionally created although it is seldom practical to create more then three of four sub-levels.

Back to top
At the first node level, immediately under the proprietary ‘Root’ node, the name of the database ‘file’, exactly as the user will see it displayed in the program executable, is entered. The only limitation being 256 alpha-numeric characters plus punctuation marks and the length of visible space to display the text in the program executable (usually considerably less than 256 characters although cut off text will be displayed in a pop-up window with ‘Mouse over’. Short, succinct and meaningful names are though recommended and if creating large numbers of listed databases then consistency in style and capitalisation, word order etc is recommended for clarity.

Successive sub-level nodes which may for example be included to sub divide a parent model range into more specific individual types can be entered. These sub-level nodes can be in groups but must always be separated from the node above by an intermediary node and this must be given the proprietary name ‘SubItems’.

A typical arrangement might therefore look something like:-

Specifically identifiable data and text is entered against Nodes against ‘Keys’.

A Key will always have a specific function and the type of data must be assigned to the appropriate Key type. The list of Key types is as follows:-

Back to top

	Key	Assigned purpose	Meaning
	B	Byte	Used as program ‘switches’ with minimal memory requirement.
	I	Integer	Whole number from 1 to 4294967294
	L	Large Integer	Whole number from 4294967295
	F	Floating Point	Number optionally including decimals
	D	Double Precision	Floating Point with high precision (8+ decimal places)
	C	Currency	Eg £200.45, €200.45, $200.45, ¥200.45 etc.
	S	String	Text. Used for information and also for naming ‘Titles’
	Feb	Date	Eg 29/08/2021
	O	Blob	An embedded image. Typically a Bitmap.

Back to top
S Keys (String) are used in particular to name ‘Titles’ which are then recognised in the program executable by their given names, retrieved and displayed, for example in an array of results.

Some ‘Title’ Key names are proprietary and ‘hard coded’ into Mistral’s compiled program executables. Others may be optionally added or created by the database designer. The full lists of Titles appear in each database and some names are common from one database type to another. Removing or changing a proprietary Title Key name may have the effect therefore of preventing part or even all of a program from working. The rule therefore is "Don't do it!" Users may add new Title Key names but it is extremely unwise to remove any that already exist in the system. The example below is of a proprietary Title Key and one that should not be altered or used for any other purpose than the obvious (and it isn't a type of fruit!).

- which may be accessed by both the Cooler databases and Condensing Unit databases and naturally will display the same type of electrical information Eg 230/1/50.

One of the most common sources of error in programming is where data of one type is attempted to be placed against a Key designed for a different function. Say a floating point number entered against a Key designed only for (memory conserving!) Integers. The program when attempting to access the data will not simply ‘round’ the floating point number it will stall instead and can sometimes involve hours of work in very large databases trying to find and correct it!

The simplest way to get started with creation of a new database is to open one of the ‘Templates’ Mistral provides, to then ‘clone’ it by renaming each of the three component files, taking care that identical ‘stem’ names are used against each of the three db files - #.blb, #.dat and #.idx and also ensuring that the file stem name commences with X.

Back to top
User Management and Passwords

Accessed from the top menu bar.

No password has been assigned to the Template database sets which have each been given the ‘Legacy Code’ BLK. Do not forget to change this legacy code to another three character code, taking care also to check that your choice of code hasn’t already been assigned to any existing databases. Easy to check as Mistral always incorporates the Legacy Code string into the database file name and it is strongly recommended that you do likewise!

In the user management menu various users, each with their own unique passwords may be added. Whoever is granted access to the Treedb editor will of course be able to make permanent changes to the databases as shared by other listed users.

The first three User names 1. ADMIN, 2 MES and 3. MISTRAL are all proprietary and must not be removed (or the programs will not find the database!).

Database file sets of either #.dat and #.idx or optionally #.dat and #.idx plus #.blb (if any image files such as company logo in Bitmap format have been added, must be filed in the same folder as the program executables that access them.

These are:-

Each of the above 8 executables opens the single Mistral MES.EXE (Mistral Equipment Selection) via one of 8 different ‘doors’. More than one ‘door’ can be opened at a time. Eg Coolwind simultaneously with Condunit, whereby this will automatically launch a refrigeration Balance Point procedure.

Back to top
Importing and Exporting blocks of code and data.

Whilst Treedb’s user interface is reasonably friendly (by the standards of high powered professional software at least!) it can be somewhat time consuming when attempting to deal with the ‘digital diarrhoea’ that many manufacturers have turned their product range varients into in recent years. In particular due to the advent of computerisation which now afford almost infinite product design interpolated and even extrapolated ‘varients’. Most of which will never see the light of day, as everyone knows!

Mistral has therefore devised a method whereby large chunks of data may be exported, ‘cloned’, added to and edited outside of the Treedb structure using a more humble Word processor (the more humble the better! MS Word is favoured) and then re-imported.

Highlight the node immediately above the data to be edited then right click Mouse button. A dialogue menu will appear requesting the file be given a name, a file ‘path’ and also a small menu of data type. Select file type TDB.

Edit as required and then re-import by clicking upon the node immediately above the one from which you used to originally export.

Be warned. This will have the effect of permanently and irretrievably over-writing whatever was there before! Again the three primary rules are Back-up, Back-up and Back-up!

Another important point worth noting is that if inadvertantly you create a duplicate node (by node name) then only the last to appear in the TDB file will appear to be imported as this will automatically over-write any predecessors using the same name.

Back to top
A list of unit coolers for example that originally looked like this:-

Model 10
Model 11
Model 12
Model 12
Model 12
Model 13
Model 14

Will end up looking like this:-

Model 10
Model 11
Model 12
Model 13
Model 14

If you really need to have three different Model 12 each with some slight variation then each one needs to be given an individual identification. Thus:-

Model 12a
Model 12b
Model 12c

Back to top

Links

Nodes may be 'Copied & Pasted' into new locations. Thus 'cloning' common data for access under different set of conditions. For example a large set of data for a model range of unit coolers may be identical regardless of which refrigerant applies. The only diffence being a refrigerant duty correction factor and which is applied from outside of the SubItem data store.

Large model ranges, copied into numerous SubItems can though consume large amounts of memory. Not just creating ongoing problems with large file handling but also slowing program operation.

A solution is provided whereby Nodes may be pasted as 'Links' to the data set stored under a parent node.

This also provides the advantage that edits to the parent data set will automatically apply to all of the 'daughter', linked data sets.

A pitfall however is that if the parent node is removed or even temporarily disabled this will have the effect of breaking any 'linked' sets. Worse, the broken links will not be immediately apparent unless the entire database is entirely 'drilled down' for checking purposes. Naturally broken links can easily be repaired by repeating the 'Paste as Link' procedure.

Back to top

Copy & Paste

Copy & Paste function in Treedb is limited to working within a single database only. If data is required to be copied to another database, even one that is open concurrently, then the data must be 'Exported' from the origin database and 'Imported' by the recipient database.

Copy & Paste function in Treedb is limited to a single node or a single key at a time.

Back to top

Switches (using single Byte Keys)

Mistral's MES RAC Equipment Selection programs make much use of 'switches' that are designed to provide a variety of functions. Typically to control program flow, for example to bypass questions appearing that have been rendered redundant by previous input. For example, it is pointless displaying a menu demanding a user choose between Electric coil defrost and off-cycle defrost where, due to the room operating temperature off-cycle defrost would not be a viable choice. A single Byte is used in this example to control what the menu displays. Byte 1 = off-cycle defrost, Byte 4 = Hot gas coil with electric drain pan defrost, 8 = Electric Coil and drain pan defrost.

There are many other examples and these are each readily seen under appropriate, meaningful Node names within databases. Using a database template ensures they will be available.