Suggestions Implemented in Version 1.0.0.17 (Released July 4 2017)

oThe change is related to the “If the ApiTableConvert…” bug. The ApiTableConvertAllToSQL internally uses the ApiTableConvertToSQL_Ex function. The change was proposed by Marco Kuipers. He argued that if a conversion of a table from embedded to SQL e.g. failed, the logic should always see what table the Filelist.cfg points to. This means that if the Filelist.cfg is changed so that it yet again points to an embedded table (and the pnVersionNumber is increased), the table should be converted to SQL again. This was not how it used to work. All framework logic first checks if a change has already been performed, and if it has nothing happens. This is to guard for if the database version number accidentally or otherwise is set to a lower value (or zero). This logic is in place for numerous functions. This meant that even if the Filelist.cfg was changed to point to an embedded table, nothing would change, as the SQL table already existed. However, Marco has a strong point in that it is probably quite a common task that you need to re-convert because something went wrong and you would expect that changing the Filelist.cfg would fix it if run again. The change that has been done is that if the Filelist.cfg points to an embedded table and the table exists in SQL, the SQL table will first be renamed with an added GUID at the end. Then the table will be converted again. A warning will be written to the error log file describing exactly which table name(s) were involved. But as this is not considered an error the error log from the data folder is not shown automatically after a conversion. You need to read the log file to see this. Note that this won't happen if you simply just reset the database version number to zero or so and run it again. It will only happen if you also change the Filelist.cfg to point to an embedded table.