Converting DB V4.1F-V4.3C applications

data & index files

Data files are converted using the utility program ctcv43 provided with FairCom DB. Index files associated with these data files should then be rebuilt using the FairCom DB function, RebuildIFile().

Stand-alone index files are converted with the programs ctin43 and ctindx provided with FairCom DB. ctin43 must be linked with your V4.3 library. It produces a flat key file for each index. ctindx is linked with your FairCom DB library. It creates a FairCom DB index from the flat key file produced by ctin43.

ISAM information

ISAM Parameter files and Incremental ISAM Structures are compatible. The tfilno field has been added to the IFIL structure. The aidxnam, altseq, and pvbyte fields have been added to the IIDX structure. See Incremental ISAM Structures in the FairCom DB Programmer's Reference Guide for more information on these structures.

With parameter files, make sure the RTREE setting in ctoptn.h is correct.

Header info

FairCom DB applications cannot directly access the index file headers via the(ct_key + filno)->member reference. Instead, use the GetCtFileInfo() and GetSymbolicNames() functions, part of the FairCom DB library, to get the information.

For example, the data record length is accessible with the following expression in c-tree V4.3: (ct_key + filno)->reclen. In FairCom DB the record length is returned by the function call GetCtFileInfo(filno,RECLEN).

GetCtFileInfo() returns a long integer since it is also used to return header values such as the file size. All references of the form “extern CTFILE *ctnum;” must be removed. If you are using such a statement, then you must rely on the GetCtFileInfo() and GetSymbolicNames() functions instead.

Length params

All length-related parameters have become 4-byte values. We now provide function prototypes which should catch (and/or correct) this change. For example, in REDVREC(datno,recptr,bufsiz), bufsiz is now a 4-byte quantity.

Function returns and parameter changes

The following functions have undergone parameter changes between c-tree V4 and c-tree Plus V6:

frmkey

If you use the BuildKey() function, short name frmkey, it now takes an additional parameter specifying the length, as a 4-byte quantity, of the record buffer from which the key is extracted. See the function prototype for BuildKey() in CTDECL.H.

current ISAM record

cur_recno[ ] and cur_image[ ] no longer exist. Also, it is no longer necessary to use two buffers for record updates, although using two buffers will NOT cause any problem for FairCom DB. FairCom DB maintains the necessary information internally for each user.

To determine the current ISAM record position, use GETCURP(datno) instead of cur_recno[datno]. To reset the current ISAM record after a successful rewrite, use UPDCURI(datno,SWTCURI) instead of manipulating cur_recno and cur_image. See "ResetRecord" or "CurrentFileOffset" in the FairCom DB Programmer's Reference Guide for additional capabilities.

To set the current ISAM record to a specified byte position (and/or record image) use SETCURI(datno,recbyt,recptr,bufsiz), where recbyt is required and specifies the record position. If non-null, recptr points to a record buffer containing an image of the data record. If non-zero, bufsiz (a 4-byte value), specifies the length of the record buffer. If recptr is non-null and bufsiz is passed as 0L, then bufsiz is assumed to be the record length defined for the file at the time the file was created. For variable length files, this corresponds to the fixed length portion of the file.

Key segment info

If you have accessed key segment information (such as a segment length or segment mode), you can now retrieve it nia a call to:

ctgetseginfo(keyno,segment_no,mode)

where segment_no is a zero-based segment number, and mode is one of the following:

#includes

Be sure to change the FairCom DB include files to the following:

#include "ctreep.h"

Note that ctaerr.h includes the definitions for uerr_cod, isam_err, and isam_fil. It is not necessary to include ctifil.h (as specified in the manual) since it will be included automatically.

old key types

Key types 1, 2, and 3 have been phased out. they supported integer and floating point keys. You can use appropriate key segments to support all of these types. Change the key type to 0, unless you desire key compression, and modify your ISAM key segment modes. If you application only uses the low level functions, you can transform the keys as required using the TransformSegment() function described in the FairCom DB Function Reference Guide.

Lock table size

c-tree V4.X utilized an internal lock table that supported 32 concurrent locks by default, #define MAX_LOCKS 32. To alleviate this artificial lock limit, FairCom DB dynamically allocates a lock list instead of a more static lock table. The number of locks available to FairCom DB is now constrained by available system memory.

TRANSACTION

The TRANSACTION() function supported in c-tree V4.3, for purposes of keeping a server from shutting down in the middle of an application procedure, now simply returns without error. It causes no action to be taken.

FairCom DB supports extensive transaction processing in the Server mode via the Begin(), Abort(), Commit(), SetSavePoint(), and RestoreSavePoint() functions.

TFRMKEY

FairCom DB supports the automatic calling of TransformKey(), short name TFRMKEY(), to transform target key values used in ISAM level search routines. If you use the traditional FairCom DB functions to initialize FairCom DB, InitCTree(), InitISAM(), OpenISAM(), or CreateISAM(), then this automatic feature is disabled and your existing application will be unaffected. If you use the extended forms of these functions (InitCTreeXtd(), InitISAMXtd(), OpenISAMXtd(), or CreateISAMXtd()), then you must set the userprof parameter to USERPRF_NTKEY to disable the automatic calls to TransformKey(). Otherwise, your existing calls will be followed by the automatic calls, which will cause problems.

FPUTONLY

There is no longer a FPUTONLY disk I/O protocol. FairCom DB now lets you select on a file-by-file basis whether or not to force updates directly to disk. OR the ctWRITETHRU constant (64) into the file mode to get the same affect as the FPUTONLY I/O protocol.

DOSFLUSH

DOSFLUSH support is being phased-out. As distributed, DOSFLUSH will only become effective in the FPUTFGET, Standalone Multi-user, configuration. If necessary, add DOSFLUSH to your CTOPTN.H configuration file. CTOPT2.H contains preprocessor commands that turn DOSFLUSH off if NOTFORCE is selected.)Transaction processing provides a much more effective means to ensure the consistency and completeness of the data.

r-tree® / d-tree™

Applications using Version 1.1 of the r-tree Report Generator or Version 3.1 of the d-tree Development ToolBox require updated versions of these development tools.