Currently, there is no UI specific to creating these smart folder-type fields, but users can easily modify existing examples:

Options: <source>SELECT ItemID, [ItemID]>0 AS ItemIsBold

WHERE ((InStr([ItemFont],"|B|")<>0));

*** This used to work, but no longer works now ***

At point 1, we see two items the font of which is in bold. At point 2, we see that there are apparently no items in bold anywhere in the IQbase. Perhaps the way in which the bold type style is stored has changed?

In the next example, we are looking for data that contains the word "Somiro":

Options: <source>SELECT ItemID, [ItemID]>0 AS ProjectSomiro

WHERE ((InStr([Item],"{Somiro}")<>0));

*** This does not work (although I am fairly sure that it used to do so). If you create a grid based on the field ProjectSomiro, it appears to be empty. I have run this example in an IQbase based on the sample data.

Figure 4 Display of a grid based on the field Project Somiro

Interrogating system data in InfoQube

InfoQube functions, in part, because it incorporates what is effectively an active data dictionary. What this means is that the operation of the product depends upon system data which can be accessed by the IQ user by means of SQL queries.

In this example, I have created an SQL query and used it in a grid in which I wish to make a list of all the field names currently in use in a particular IQbase.

Figure 5 shows how I have constructed the necessary SQL statement. Note that it is not clear to me why it is necessary to include an ID field in the query string. I assume that this is necessary because when creating a grid, it is necessary to tie together the field values from different fields. Unfortunately, the documentation on smart fields is silent on this issue. I would like to be able to improve it, but cannot do so without assistance from Pierre.

Figure 5 Building up the necessary SQL in an Excel spreadsheet

Figure 6 shows how I have used the SQL string in the definition of a field called FieldName:

Figure 6 Defining the field in the IQbase Field Properties

Figure 7 shows what happens when a grid is created based on this field. Only one row is returned. The IDitem appears to correspond to a single new item which however does not appear in a grid based on item.

Figure 7 Result: only one row which contains no useful information

Just to prove that smart fields can be made to work, let’s examine this case. I want a list of items which include the word “Gregory” in the text. (Yes, I know there are easier ways of achieving this, but I am just trying to illustrate a point here…).

Note that I have unintelligently based this example on one of the examples that Pierre gives in the standard documentation for the product. Therefore I do not know why it is necessary to include itemID, much less [itemID]>0 - which will always return true, I think. If I now create an eponymous grid (that is to say, a grid with the same name as the field), I get fairly intelligent results (Figure 9):

Figure 9 Results of using the smart field Gregory

 The source of this field, that is to say, the data upon which it is based, is a system query called ¯qItem. This is the way in which the InfoQube product actually implements fields; for each field there is a system query whose name is the name of the field preceded by the characters “¯q”. Thus in this case the query is called “¯qItem”.

The examples given by Pierre in the system documentation frequently use underlying InfoQube system data, indicated by the use of the  macron character, "¯", Windows key alt +0175. It is unclear to me when it is necessary or advantageous to use system data in this way since it is frequently possible simply to use the name of the field exactly as it normally appears in InfoQube. However, that is not always the case – my earlier example of obtaining a list of field names is an example of where it is essential to use this underlying system data.