It is possible that the internal db became corrupted, but more often we’ve seen this caused by the logging system putting too much data in there. The problem is that error logging gets stored to the same db as configuration, and if the user sets it to log for many days, or if the system that trims the data hits an error for some reason, the file can grow to be very large, and can sometimes cause problems.
If you make sure that “debug” logging is not on and that you limit the records to 1000 as it is set by default, you shouldn’t have a problem.
Still, we have seen actual corruption in some cases. It’s rare, and has always been limited to the error log table.
In any case, the internal database system that we use (sqlite) does a good job of isolating corruption. If you have a FactorySQL system_database.fdb file that isn’t working correctly, you can usually recover fairly easily by using the included sqlite3.exe tool to “dump” the database and then load it into a new file.
For example:
...Inductive Automation\FactorySQL> Utilities\sqlite3.exe system_database.fdb .dump > outfile.sql...Inductive Automation\FactorySQL> Utilities\sqlite3.exe new_database.fdb < outfile.sqlOf course, FactorySQL should be stopped before you do this. Then move the old file, and rename the new file to “system_database”, and restart FactorySQL.
Regards,