Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Although we do our utmost avoiding Quaestor to crash, disaster can strike (also due to other reasons than Quaestor). To avoid loss of information, Quaestor is able to save backups of knowledge bases and projects at regular intervals (see also Backup File ).

Moreover, and very important as a tool for developers, you can save these backups with a time stamp, enabling several versions of our backups to be stored. This does not only save time when Quaestor or your computer crashes, it also enables you to go back to a previous version of your development version.

...

As it is common practice to have a development area and a production area, we will only mention the fact that it is important to have a good separation between your development area and your production area in order not to overwrite a released knowledge base with a development version. In Quaestor you are able to work with personal profiles (please read aboutabout startup behavior for some specific start up behavior and default setting issues). These profiles enable a knowledge engineer to efficiently work on different knowledge bases in different area’s requiring different Quaestor directory settings by switch between these profiles.

...

Furthermore you can see information on the latest modification date and time, who has done this modification to a knowledge base and with which Quaestor version which Quaestor version this was done.

2.3 QKnowledgebaseVersion parameter

In addition to this generic information, as a knowledge engineer you can actively manage versions by means of knowledge in the knowledge base.

Read in QKnowledgebaseVersion for more detail.

2.4 General remark

...

3.1 Knowledge base protection

 

See Knowledge base protection for more detailed info. It is important to know that by default knowledge bases are protected against deleting frames

...

In KE mode you can make any modification you want with one exception: you cannot delete frames without removing the delete protection.

The reason is that in Quaestor all in Quaestor all knowledge is represented by frames with a frame number. Thus, every parameter, relation, constraint, function is stored in a frame. In the present architecture (based on a long history of Quaestor use of Quaestor use and development), Quaestor will  Quaestor will renumber the frames the moment you delete one of them. This is no problem as long as you did not use the knowledge in solutions. However, the moment you have made projects based on the knowledge base, removing frames in the knowledge base will result into corrupt project because the relations between frame numbers in your solution will not correspond with the actual content of these frames.

In Quaestor we In Quaestor we have made checks in order for you to still load old projects with the modified knowledge base. And most data will still be available in the project. However, the solutions might be broken and have to be recalculated. Realize that, when relations are removed from the knowledge based that are used in a solution, this would be the case anyway.

So deleting of frames is only possible when you actively remove the delete protection through the File menu item "Allow deleting frames". Furthermore, you should only delete frames you have just added and you are sure of that are not yet used in any project.

...

While adding and modifying knowledge it is important to document its reference. In the reference and data slots of the Frame Viewer you can add this content. For a parameter we advise at lease to provide its dimension and one small description, ideally followed by some more back ground text (the first line, until the first carriage return, can be presented as identification in the Workbase). See also Documentation of knowledge in the Wiki.

Please note that the same can be done for relations. In this case the reference slot can be accessed by typing in the second text window of the Frame Viewer below the “-X-“.

When you have modified data, you can document the modifications in this same area. When you want to keep information on modifications separate from the reference text, you can also use the data slot. However, do not use full Quaestor syntax full Quaestor syntax and the @ symbol as this can be recognized as syntax in the data slot.

While adding and modifying relations and constraints, Quaestor will  Quaestor will add change log information automatically. In the data slot of relations and constraints, Quaestor will  Quaestor will provide to lines:

@ENGINEER:LoginName 
@LASTCHANGED:Date at Time

...

  1. Check whether you have no red crosses and red relations or constraints;
  2. Make sure you have modified your version number(s);
  3. Be certain your modifications are functioning properly. For this purpose use a known benchmark and re-run this benchmark checking all results;
  4. When this validation is satisfied, open (a copy of) an old project and start an old solution to check for possible compatibility problems;
  5. When this is satisfied, write a release document to inform your users about the changes and what they may and may not expect. Optionally add these notes to your knowledge base before releasing;
  6. Distribute the knowledge base with all documentation to the appropriate person(s) (ICT department etc.) and archive the released knowledge base version with documentation and a copy of your Quaestor executable your Quaestor executable in a separate Release folder on your development area.

...