The Holmes Page: CA-Clipper Networking

Home

Web Design

Programming

Fairlight CMI

Soap Box

Downloads

Links

Biography

About...

Site Map

File Buffers

CA-Clipper

Opportunities

Tips and Tricks

Networking

Internal Errors

Source Code

CA-VO

BACK TO
CA-CLIPPER
NETWORKING

To improve performance CA-Clipper buffers file data in memory. If the workstation is turned off before the buffers are "flushed", then the files will not be updated.
DBF Buffers

When a table is opened in exclusive mode, the use command establishes a buffer in memory and fills it with as many records as possible. In shared mode (which is used on a network) only the current record is buffered. This reduces performance, and is why most network program seem slower than non-network programs.
When an index is set, filling the buffer with more than one record is not useful because of the possibility of "random" record movement. The next record in the index will likely not be the next record in the table.
NTX Buffers

The set index to command establishes and fills a variable size buffer in the "R" region, or in expanded memory.
To ensure that the disk is updated immediately, you should manually flush the data, via the commit command (after replace).
The buffer is automatically filled via a buffer concurrency check. In other words: the buffer is refreshed if it is out of date, or it is used as-is if it is not out of date. This capability is lacking in NDX files.
COMMIT (to flush buffers)

Commit flushes (writes) the data in all Clipper buffers to DOS. The command then checks the DOS version. If it is greater than or equal to 3.3, it also calls DOS function 68h, which flushes the DOS buffers to the disk, unless intercepted by network software.
On a stand-alone machine, commit writes the data to the disk:
Clipper buffers > DOS buffers > [optional disk cache] > disk
When network software is loaded:
Clipper buffers > DOS buffers > network software > file server > [disk]
Note that the network software will flush the buffers to the file server, but the file server may not write to its hard drive. The file server buffers will be written when the file server caching algorithm decides that it is appropriate. You can assume that the file server is providing efficient buffering, and that it is protected with a UPS.
Use commit after doing a replace. There is no penalty for calling commit too many times; an internal flag is used to indicate whether a commit is actually needed.
Under any MS-DOS version, you can use the fopen() and fclose() functions on a dummy file to force MS-DOS buffers to write to the FAT. This is particularly good for versions of DOS prior to 3.3.
GOTO RECNO() (to refresh buffers)

Another user on another workstation may have changed the record between the time CA-Clipper first read the record into the your buffer, and when you use the values in your program.
Use goto recno() before referencing table data to assure that the most recent copy of the data is brought into the buffer. This function call moves the record pointer to the current record, which actually causes CA-Clipper to re-read the data from the record into the record buffer.
Clipper buffers < DOS buffers < network software < file server < disk
Typical code would be something like this (highly simplified):

    goto recno()             // Refresh the record buffer.
    @ 10, 10 say "Name: " + CUSTOMER->NAME
    @ 11, 10 say "City: " + CUSTOMER->CITY

In the following code rlock() refreshes the buffer, so goto recno() is not needed. Also, unlock flushes the buffer to DOS, but commit is included to ensure that the buffers are flushed all the way to the disk.

    if rlock()               // So no one else changes.
       @ 10, 10 say "Name:" ;
                get CUSTOMER->NAME
       read                  // Allow the user to edit.
       commit                // Flush changes to disk.
       unlock                // Allow others access.
    else
       ? "Unable to lock the record for editing."
    endif