Converting Superbase Databases to Superbase NG

Converting Superbase Databases to Superbase NG
	Chapter 11. Converting Legacy Superbase

Converting Superbase Databases to Superbase NG

There is a very useful tool supplied in the Utilities directory called sbf2sbm.smp, which converts legacy Superbase database files into Superbase NG's *.sbm 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 Superbase NG 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 the older Superbase LAN and Distributed LAN networking.

Running the SBF2sbm tool presents a dialog window like the one below:

Image of the SBF2sbm dialog.

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 Add button, which let's us select the *.sbm 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).

Image of the SBF2sbm dialog ready to convert.

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.

Note

	Note
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 `SCHEDULE.SBF`, since it turned out to have multiple virtual calculated fields, one of which had a unique index on it. In order to successfully import the table, the fields need to be changed to normal fields (not virtual), and the content needs to be updated by doing a Superbase UPDATE that specifically sets each of these fields to be equal to itself.

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 SCHEDULE.SBF, since it turned out to have multiple virtual calculated fields, one of which had a unique index on it. In order to successfully import the table, the fields need to be changed to normal fields (not virtual), and the content needs to be updated by doing a Superbase UPDATE that specifically sets each of these fields to be equal to itself.


So What's the Good News?		Converting the Forms