<< Click to Display Table of Contents >> Navigation:  Gekko User Manual > User manual introduction > Databank search

Databank search is an important concept in Gekko, alleviating the burden of always having to state the databank name when variables in other databanks than the first-position databank are used.

 

Databanks search can be controlled with an option, or via the MODE statement, cf. the next section. In general, databank search can be practical, but the user should be aware of the pitfalls, especially if several open databanks contain variables with the same names.

 

The remainder of this page tries to answer the following question: In statements like y = x; or prt x;, where should Gekko look for the variable x, if it is not found in the first-position databank?

 

---

 

The option and MODE

 

The option that controls databank searching is the following:

 

 

Per default, this option is set to yes, since Gekko starts up in mixed-mode. In so-called sim-mode, the option would be no. Regarding modes, using the default mixed mode is recommended in general. If sim-mode used for modeling, prt x; will fail if x is not found in the first-position or local/global databank (in that case, Gekko will not look for x elsewhere).

 

---

 

How does databank searching work?

 

When databank searching is active (option databank search = yes), Gekko will look for a variable x in the hierarchical list of open databanks (cf. the F2 window that is opened when pressing the F2 key). As shown on the page about OPEN, Gekko operates with the following databanks:

 

 

So if databank searching is active, Gekko will first look for a variable x in the Local databank. This databank is often empty, since it is only used for temporary (discardable) variables. Next, Gekko looks in the first-position databank, which is often the Work databank. If not found in these databanks, Gekko looks in any other databank opened with the OPEN statement. If not found in these, the Global databank is queried at last. Note that the Ref databank is never searcheable, so a variable x without databank indicator (a 'bankless' variable) will never be found in the Ref databank (even if it exists).

 

The search hierarchy means that variables may shadow/mask each other. If searching is active, the user may put a variable x in the Global databank for later use in a system of Gekko program files (the Global databank is not affected by READ, CLEAR, etc. and is therefore practical for long-term storage of global variables). But if the system of program files creates a variable x, or opens a databank containing a variable x, the x in the Global databank is masked. For instance, the user may state x = 100;, creating a series x with the value 100 in the first-position databank. After this, prt x; will refer to this variable, not the variable in the Global databank (to refer to that variable, global:x could be used). So when databank searching is active, and databank indicators are omitted, the user should keep name collisions in mind.

 

There is another pitfall regarding databank searching, namely that deleting a variable may bring back another variable from being masked. Consider this example:

 

 

The first PRT prints x as 100, whereas the second print prints x as 200. The reason is that in the first print, x is first found in the bk1 databank, whereas in the second print, x is first found in the bk2 databank (because bk1 was closed). So closing a databank, or deleting a variable may have the consequence that a variable with the same name is unmasked in some databank lower in the search hierarchy.

 

If the variable names in the different databanks are distinct, this is not a problem, and it is practical to be able to refer to variables without always having to write the databank name. Also, in some circumstances, databank masking can be used for selection. Consider two databanks, bk1 and bk2, where the quality of the data in bk2 is inferior to the quality of the data in bk1 (for instance because bk2 is an older databank). In that case, if the databanks are opened with bk1 before bk2, databank searching works as a quality filter. If a variable x exists in bk1, this version is always used. If it does not exist in bk1, Gekko will look for it in bk2 instead. If it does not exist in bk2 either, an error will be issued. In that way, the newest version of x is always found (or an error occurs).

 

---

 

Statements without databank search

 

Some statements disallow databank searching completely in order to avoid ambiguities. In these statements, bk1:x is still understood as x from the bk1 databank, but x without databank indicator will be understood as x from the first-position databank, without looking elsewhere for the variable.

List of statements where bankless variables are never searched for
 

Note: Wildcards without databank indicator are never searched for in other databanks than the first-position databank. So the table deals with 'normal' bankless variables. In some of these statements, *:x can be used to indicate the occurrence of x in all databanks.

 

As an example, copy x to y; only looks for x in the first-position databank, and if it is not found, an error is issued. If it is found, it is copied as a new variable y, also in the first-position databank. If the COPY statement allowed searching, the origin of y would be unclear, since it could origin from some other open databank than the first-position databank.

 

---

 

Note

 

Note that a bankless variable on the left-hand side of an expression is always interpreted as residing in the first-position databank. For instance, x = 100; will always put the series x into the first-position databank (implicitly using first:x = 100").  

 

Note that the Local or Global databanks are always searchable, independent upon MODE etc.