<p><span class="f_Examples">The Server Engine Settings define how the core server engine operates. </span></p>

<p class=h3><span>Server Name</span></p>

<p><span class="f_Examples">As a unique identifier, the server needs a name, which is entered in the Server Name option. </span></p>

<p class=h3><span>Max RAM</span></p>

<p><span class="f_Examples">Max RAM defines the maximum amount of physical memory the server engine is allowed to allocate for its table cache. This setting is in Megabytes (ie, 512 = 512MB). The best performance is achieved if it can be set to a value large enough so that all tables and query result sets fit into this memory. If this value is set to -1, the server table cache will use a maximum of 50% of the physical memory available to the machine. Be aware that heavy use of SQL requires additional memory to be available for SQL processing, in this case setting a too high value might cause the server to run out of address space (win32 processes are limited to 2GB physical RAM).</span></p>

<p><span class="f_Examples">The AWE server version can be used to deal with the problem of databases that can't fit within the 2GB of memory for a win32 process. Using the AWE server with a windows server OS that supports > 4GB RAM, you can as a general rule set Max RAM to (total GB RAM - 2GB). Eg, on a machine with 12GB, you can set Max Ram to 10GB (actual setting value in MB: 10000).</span></p>

<p class=h3><span>Temporary Storage</span></p>

<p><span class="f_Examples">The settings for Temporary Storage are Path and Size. NexusDB uses its own temporary storage management and files instead of using the normal windows page file. This increases its performance and allows for dedicated virtual memory allocation for the database server. The files that NexusDB creates are stored in the directory identified by the path setting and have the maximum size stated in the size setting. The files are created as maximum size when the server engine is started with a special file system flag which makes sure they are deleted as soon as the process ends, even if it is killed (e.g. via the task manager or Delphi).</span></p>

<p class=h3><span>Engine Options</span></p>

<p><span class="f_Examples">The Engine Options enable the user to change certain behaviour of the database server. </span></p>

<div ><table border="0" cellpadding="0" cellspacing="0" style="line-height: normal;"><tr valign="baseline"><td width="13"><span class=list>&#8226;</span></td><td><span class="f_Examples">The </span><span class="f_Examples" style="font-weight: bold;">read only</span><span class="f_Examples"> setting sets </span><span class="f_Examples" style="font-weight: bold;">all</span><span class="f_Examples"> databases of the server to read only. This means also that the SQL data manipulation commands (insert, update, etc.) on physical tables will fail. It is still possible though to create in-memory tables. </span></td></tr></table></div><div ><table border="0" cellpadding="0" cellspacing="0" style="line-height: normal;"><tr valign="baseline"><td width="13"><span class=list>&#8226;</span></td><td><span class="f_Examples">The </span><span class="f_Examples" style="font-weight: bold;">InMem</span><span class="f_Examples"> only option, which is restricting the database server to in-memory tables only. No tables are saved to disk if this option is enabled and thus if the server is closed all data is lost.</span></td></tr></table></div><div ><table border="0" cellpadding="0" cellspacing="0" style="line-height: normal;"><tr valign="baseline"><td width="13"><span class=list>&#8226;</span></td><td><span class="f_Examples" style="font-weight: bold;">Force Failsafe</span><span class="f_Examples"> makes the server work in failsafe mode only. Please note that this slows down the server significantly, but in certain circumstances and environment, data safety and consistency is essential. If the option is enabled the server engine writes a journal for every transaction and only if the transaction is successfully completed and the journal committed the actual transaction is considered successful. Otherwise the engine automatically applies the action set in the Failsafe mode setting. </span></td></tr></table></div><div ><table border="0" cellpadding="0" cellspacing="0" style="line-height: normal;"><tr valign="baseline"><td width="13"><span class=list>&#8226;</span></td><td><span class="f_Examples">The </span><span class="f_Examples" style="font-weight: bold;">Secure Server</span><span class="f_Examples"> option forces users to logon when establishing a connection </span><span class="f_Examples" style="font-weight: bold;">and</span><span class="f_Examples"> an admin user to log on to the server user interface. Please look at the following paragraph for more information on Users.</span></td></tr></table></div>
<p class=h3><span>Journal Engine Class</span></p>

<p>If the Force Failsafe option is enabled, this option defines which action the server takes on restart, if it finds that a previous transaction did not not successfully complete.</p>
<p><span class="f_Examples">The default option is </span><span class="f_Examples" style="font-weight: bold;">Always Rollback</span><span class="f_Examples"> (Tnx1xRollbackJournalEngine), which always undoes unsuccessful transactions. </span><span class="f_Examples" style="font-weight: bold;">Always Commit</span><span class="f_Examples"> (Tnx1xCommitJournalEngine) is the opposite, while </span><span class="f_Examples" style="font-weight: bold;">Dialog</span><span class="f_Examples"> (Tnx1xJournalEngine) pops up a dialog* and lets the user decide what to do. </span></p>

<p>* If the server is running as a service, no dialog can be shown. In this case, the Tnx1xJournalEngine (Dialog) setting falls back to the Tnx1xRollbackJournalEngine behaviour.</p>

