The last difficulty to be overcome before the components of a query have been gathered is the generation of values for the fields. Each fields' meaning has been worked out in the previous step. Simply taking a default value for each category is a possible, but certainly not a comprehensive solution to finding values. Instead we pick up the calculated similarity between the form currently worked on and forms in the Database as described before. Consequently, values of fields having the same category and belonging to a similar form are transferred to build up the new query.
This automatically solves the conflict of how fine-grained information is given in a single field. To clarify this point take, for example, a name. There could be a single field intended for a name in one form. In another form there could be two, one for the first the other meant for the last name. A new form will take the values of the more similar form to be found in the Database. Assuming it has two fields intended for the name, it will by definition be more similar to the entry in the Database having two fields as well and will, hence, get the first and the last name transferred separately, as it should be the case.
Consideration has to be given to the different types of fields, since the value a field may take can be restricted. In the case of a text-field there is no restriction on the possible values. When processing such a field, it does not need to be bothered about the transfer of the value. On the other hand, a selection-field has a defined set of values. A button is a special kind of a select having two alternatives only. When transferring a value to a field with a fixed set of possible values, the transferred value has to be a member of that set. Also, it might be considered to simply take the default value of the field or a random member of the set instead of a transfered value. Lastly, hidden types offer no room to move at all, since there is only one possible value the field can obtain.