There is a very useful tool supplied in the
Utilities directory called
sbf2sbm.smp, which converts Superbase database files into SIMPOL's
format. This reads the data file directly, so it does not require any extra action to make it available, with one
exception. It cannot read encrypted Superbase database files. In that case the file needs to be converted to a
non-encrypted database file. Just as a note, currently there is no encrypted file format for SIMPOL database files.
At the same time, since multi-user access is only via PPCS, the location of the physical data does not need to
be accessible to every user as is the case with normal Superbase LAN and Distributed LAN networking.
Running the SBF2sbm tool presents a dialog window like the one below:
As an experiment, we are going to import the database tables from the Superbase Air example that ships with all versions of Superbase 3.x (Superbase 95, Superbase 3.01, Superbase 3.02, Superbase 3.2, Superbase 3.5, Superbase 3.6i, Superbase 2001, and Superbase Classic).
To start with, we click on the
files and add them to the list for conversion. The dialog supports multiple selection, so we can select all the
files at once. Then click on the button to select the target directory (by default
it will be set to the same as the most recent source directory).
Leave the settings at their default values for the most successful conversion. Below each of the settings is explained.
Lowercase *.sbm names (recommended) — This makes sure that if the tables are being converted into separate container files, one per Superbase file, that the file names will be forced to lowercase, otherwise they will be in uppercase (like the original files from Superbase).
Uppercase table names (recommended) — This ensures that the tables are created with uppercase names. This is important if working on a hybrid solution, since SIMPOL is case-sensitive when opening the tables.
Use a separate *.sbm file for each table (recommended) — Although SIMPOL database containers can support multiple tables, there are good, performance related reasons for keeping each table in a separate container. It also makes it easier when doing updates of specific tables, or if reorganizing only one table.
Create system tables (recommended) — Unlike Superbase, SIMPOL database fields only have a data type, and whether they are indexed or not (plus if they are, an index algorithm and precision). Things like the display format are not part of the core field definition, but the system tables store additional information such as the display format, help string, share name (which can be different to the field name) and other useful bits. Using the system tables means that the standard PPCS server program can automatically share the table and have it look just like the original from Superbase (minus calculations, etc.).
Overwrite existing files — If selected, it overwrites an existing file without asking. If it is not selected, it will not ask, and will not overwrite.
Copy data — This determines if the table is created empty, or if all the data is also transferred.
One thing that it is important to understand, is that this tool cannot resolve the calculations for a virtual
field. If the table definition has virtual calculated fields, and if those fields are unique indexes, then the
import of that table will fail. This was the case with the