|
|
|
Transaction Control
All c-tree files (.dat and .idx) are FPUTFGET and do not support transaction control. (All system tables and housekeeping files, including FAIRCOM.FCS, are under full transaction control).
The FairCom DB Standalone SQL Service does not support transaction control of the data files as it is tied to the multi-user standalone database model, which also lacks transactional support. Therefore, be very careful if you choose to update your data files through the ODBC Driver as you lose a large degree of database consistency, which would be taken for granted with a fully relational DBMS, such as FairCom DB SQL.
For example, if the system crashes, or a routine error occurs in the middle of a large update that touches multiple rows or tables, your files will not be rolled back to their original consistent state. You might end up with a few of the tables, or rows, updated, and a few of the tables, or rows, without the updates. ALTER TABLE operations have the potential to lose entire tables if an error were to occur during the operation.
Note that FairCom offers a full ACID-compliant transaction processing layer with its FairCom DB SQL database server technology.
Backups
FairCom DB Standalone SQL Service does not provide quiesce functionality to help during backups because the FPUTFGET standalone model does not support transaction control. FairCom DB Standalone SQL Service cannot provide these extended features because it is not providing a central point of control.
Simply copying files can work in this model, provided users are not actively working against them. Note that copying files while they are being updated can result in "corrupt" opens when restored. Therefore, it is important to ensure all applications are not active against the data when doing backups using the FPUTFGET standalone model.
VSS_WRITER is not recommended for backups of FairCom DB Standalone SQL Service (or any FPUTFGET standalone applications) because it expects a single point of control for all files, which is not provided in this model.
Paths
The path to the system table is crucial, as it is a physical path requirement from the import utility.
FairCom DB Standalone SQL Service will need to access the system table and other FairCom system files. For best performance, install FairCom DB Standalone SQL Service on the same machine as these files. If it is installed on another machine, it will need a network mount to access them.
Permissions
Tables require permissions for access by ODBC. Two types of permissions are required: OS file system permissions and SQL permissions.
OS File System Permissions:
The FairCom DB Standalone SQL Service will need to have Read-Only or Read/Write to the data, index, and system files shared by your Multi-User Standalone users.
When you select an ODBC data source, you may have the option of selecting Read-Only instead of Read/Write. The Read-Only option will keep you from inadvertently altering data in your database and is our best practice recommendation.
SQL Permissions:
ODBC access requires that tables have been granted SQL permissions using the SQL GRANT command.
ODBC Registry Entry
ODBC driver information is stored in subkeys of the Windows registry.
User data sources are stored under the HKEY_CURRENT_USER key and are available only to the current user. System data sources are stored under the HKEY_LOCAL_MACHINE key and can be used by more than one user.
For user data sources, the complete registry key is HKEY_CURRENT_USER\Software\ODBC\ODBC.INI.
The ODBCINST.INI subkey is a subkey of HKEY_LOCAL_MACHINE, which describes the number and types of ODBC drivers installed on the system. The ODBC Data Source Administrator reads the subkey when it invokes the driver’s setup DLL to add or modify a data source for the driver.
ODBC Drivers - 32- vs. 64-Bit
ODBC uses separate drivers for 32-bit and 64-bit applications.
If you are installing the FairCom DB ODBC Driver on a 64-bit system, you may need both drivers. Match the number of bits supported by your ODBC-compliant application with the appropriate version of the FairCom DB ODBC Driver. For example, most third-party applications are still 32-bit and therefore will require the 32-bit driver even though they are running on a 64-bit operating system.
Architecture Mismatch
In trying to connect to the FairCom ODBC data source, you may see an error message along these lines:
Microsoft Data Link Error
The specified DSN contains an architecture mismatch between the driver and the application.
This generally indicates the ODBC application in use does not match the number of bits supported by the ODBC Driver that is loaded. For example, the application is a 32-bit application, and the ODBC Driver is a 64-bit driver. To resolve this error, ensure the number of bits match between the ODBC Driver and the application.
Rebuilding
Should the system table (superfile) become corrupted, the ctscmp (or ctsbld) utility can be used to rebuild that table.
TCP/IP Port
The FairCom DB Standalone SQL Service uses the standard FairCom SQL port: 6597
This port must be open on your firewall.
Locking Issues
The FairCom DB Standalone SQL Service uses the same Windows-based locking facilities as the FairCom DB multi-user non-server programs. For details, see the "Standalone Multi-User" chapter in the FairCom DB Programmer’s Reference Guide.
Starting and Stopping the Service
An entry in the Windows Service menu called "FairCom-SQL" was created during installation. The Windows Service Console can be used to stop and start this service in the same manner as any other Windows service.
Rebuilding Corrupt Files
To rebuild any data/index file, use the same approach you use today: Call a standalone rebuild function on the table. The ctrbldif utility (standalone version) is appropriate in this regard.
