Prepare the Database Server (SQL Server or Oracle)
The ReliaSoft desktop applications, XFRACAS and SEP are all designed to connect with the same database on either SQL Server or Oracle.
If you need to establish a new database, the following considerations apply for preparing the database server. Later, you will use the admin utility to either create the database or connect to an existing one. (See Create the ReliaSoft Database (if Applicable) and Update the Configuration File.)
Setting up for SQL Server or Oracle
SQL Server
- Make sure you have the latest version of SQL Server running. To do this, run the following query in Query Analyzer: “Select @@version”. This should return a value like “Microsoft SQL Server 2005 - 9.00.3042 (Intel X86)” or “Microsoft SQL Server 2008 R2 - 10.50.1617 (X64),” depending on which SQL Server service pack you have installed.
- Make sure you know the SQL Server Name. This is a local server name or IP address so the IIS machine with the .NET application can connect to the database. These instructions assume that you will use a default instance of SQL Server to host the ReliaSoft database (e.g., SERVERNAME). If not, you must specify the instance when you enter the server name (e.g., SERVERNAME\INSTANCENAME).
Oracle
For easier support, we recommend installing the SQL Worksheet (available with the Enterprise edition) or Oracle SQL Developer (free to download from the Oracle website).
Replication and Backups
XFRACAS, SEP and the ReliaSoft desktop applications cannot be deployed with bi-directional (peer-to-peer or merge) database replication. They are designed for use with a single back-end database and do not handle conflict detection and resolution. It may be possible to use a ReliaSoft database with uni-directional (transactional or snapshot) replication; however, this is likely to affect performance, and you must test to evaluate the impact in your particular situation. This type of use is not recommended or supported by ReliaSoft.
For the purpose of disaster recovery, we recommend establishing a regular schedule for database and transaction log backups and storing these backups in a location that is protected from potential failure of the application's database server. If an issue occurs, you can restore the most recent database backup (e.g., nightly) and then restore subsequent transaction logs up to the point right before the failure.