SIMPOL Documentation

In traditional desktop database environments such as Superbase and dBase, there are numerous commands in the programming languages to handle the various tasks associated with working with database files. In some cases the command set can be quite large and often somewhat ambiguous in that command names may be reused in various combinations with slightly or even widely different effects. The result is that generally the programmer is required to remember a large number of commands with various parameters in order to accomplish very basic manipulation of the database. Since in most cases these commands are considered key words in the language, they also reduce the available group of obvious variable names that can be used by the programmer.

SBL has a large array of database oriented commands that are composed of one or more key words in the programming language. For example, in Superbase Basic Language (SBL) there is a wide variety of SELECT commands. These include:

Each of these commands also has various parameters that can be appended to the end or in some cases inserted earlier in the command. There are numerous other commands that exist purely to manipulate databases.

One of the biggest issues by far, however, which people run into when working with these languages for manipulating databases is what I call the current everything problem. The assumption is made that files are globally visible and that field names in files are globally visible identifiers. Although that simplifies things when doing simple things, it results in great complexity and confusion when doing more complex things. It also results in limitations such as not being able to open the same file twice in the same instance of the program because there would be no way to differentiate between the two versions (or only with great complexity).

A common error made by SBL programmers is that of selecting a record using an index different to the current index as seen from the user's perspective, and then after establishing that the selection worked, reselecting the record with a lock. Unfortunately, the second selection occurs using the current index, which is not that used when they selected the record the first time and so they lock the wrong record and possibly make and save changes to the wrong record. See the code in the example below:

' The current index is LastName and the current file is ADRB
SELECT KEY 12345 FILE "ADRB" INDEX RecNo.ADRB
IF FOUND ("ADRB") THEN
  ' Here the SELECT CURRENT LOCK operates on the LastName
  ' index which is whatever was current before the
  ' SELECT KEY took place against the RecNo index.

  SELECT CURRENT LOCK

  ' Correct would have been to use:
  ' SELECT CURRENT LOCK FILE "ADRB" INDEX RecNo.ADRB
  ' but this is a common error.

  AccountBalance.ADRB = AccountBalance.ADRB + deposit%

  ' The program now assigns the deposit amount into the wrong
  ' account number and stores it. This problem will be difficult
  ' to track down because the deposit to the wrong account won't
  ' always happen. If the current index is RecNo, then the code
  ' will work, if it is not, then the deposit will be made to
  ' whichever record is current in the current index.

  STORE
END IF

In an object-oriented environment these kinds of issues don't exist since all selections are made as a call to a method of an object, so there is no way that you can accidentally call the wrong object (at least not easily).