This help section describes the Database Settings dialog and the database management in ORF.
ORF has four tests which rely on databases: the Auto Sender Whitelist test, the Greylisiting test, the DHA Protection test, and the Honeypot test. When enabled, the above tests will use a Private Local Database file by default (stored with .abs extension in the ORF directory) created by the embedded database engine of ORF, but you can also use an External SQL Database. Make sure to read the notes below about selecting the database type that suits your setup the best.
The dialog allows you to select the type of the database and configure the path where the database file is stored (Private Local Database) or configure the database access parameters (External SQL Database).
The currently configured database can be managed by clicking the Manage button. Note that actual management is performed using the ORF Service, so it must be running to manage the database.
ORF can store various test data either locally or on an external SQL server. A comparison of the database options can be found below:
| Property | Private Local Database | External SQL Server |
|---|---|---|
| Created and maintained automatically | Yes | No |
| Does not require another software | Yes | No |
| Can be shared between ORF instances | No | Yes |
| Can handle more than 50,000 emails/per day | No | Yes |
| Data can be edited from external program | No | Yes |
Private Local databases are created automatically on demand in the local file system and practically they do not require any maintenance. However, they cannot concurrently serve requests (hence the lower performance) and they cannot be shared between servers.
External Databases require manual setup (this may include Microsoft® SQL Server® setup, too) which may take a few minutes, but they scale well, the databases can be shared and you can use the native database editing tools of SQL Server® to view the database contents.
We occasionally receive reports about unexpected database corruption issues from Private Local Database users which we were unable to reproduce so far. Such corrupted database files can be fixed by clicking the Repair button under Manage, or (if it does not help), by stopping the ORF Service and deleting the affected .abs file: ORF will create a new, empty one automatically.
To avoid such corruptions, we recommend using External SQL Databases whenever it is possible.
Our website offers downloadable guides that explain the process. Please visit the ORF Database Setup Guides page.
The service automatically modifies tables and columns to fix inconsistencies in the ORF database, such as missing columns or incorrect column properties. To perform these operations, the database user specified in the connection string needs permission to run the following commands: SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, and ALTER.
Alternatively, connect to the database with a user having the necessary permissions and execute the script provided in the downloadable guides to resolve any inconsistencies.
Use the ORF database converter tool available on our website to migrate your Private Local Database to an External SQL Server.