home *** CD-ROM | disk | FTP | other *** search
/ PC Press 1997 July / Sezamfile97_1.iso / msdos / c / cbase11.a03 / CBASE11.ZIP / MAN / ROLODECK.MAN < prev    next >
Text File  |  1993-01-01  |  2KB  |  53 lines
  1. NAME
  2.     rolodeck - card file
  3.  
  4. SYNOPSIS
  5.      rolodeck
  6.  
  7. DESCRIPTION
  8.      rolodeck is an example program for the cbase library.  In order
  9.      to allow it to be compiled without requiring a specific screen
  10.      management library, only a minimal user interface has been
  11.      implemented.
  12.  
  13. NOTES
  14.      Below are listed a few of the more important points to note when
  15.      examining the rolodeck source code.
  16.  
  17.           o White space is significant in string data.  For
  18.             instance, " data" != "data".  Leading and
  19.             trailing white space is therefore usually
  20.             removed before storing a string in a database.
  21.             Also, embedded white space may be reduced to a
  22.             single space.  The cvtss function included with
  23.             cbase will perform these string operations.
  24.           o Names are often input and displayed
  25.             first-name-first.  For them to sort correctly in
  26.             a database, however, they must be stored
  27.             last-name-first.  The functions fmltolfm and
  28.             lfmtofml are included with cbase to convert
  29.             between these two formats.
  30.           o To prevent loss of buffered data, blkio buffers are
  31.             flushed on exit either by registering the function
  32.             bcloseall with atexit, or by using bexit in place of
  33.             exit.
  34.  
  35.      The following notes concern locking.
  36.  
  37.           o Single-tasking applications can simply lock
  38.             a cbase and leave it locked.
  39.           o Locks are held for shortest time possible; a
  40.             lock is never held during user input.
  41.           o A write lock should not be used when only a read
  42.             lock is required.
  43.           o When a database file is unlocked, it may be
  44.             modified by another process.  A record at a
  45.             given file position may be deleted, and the
  46.             empty slot possibly reused for a new record.
  47.             Because of this, each time a file is locked,
  48.             the current record must be located by performing
  49.             a search on a unique key.
  50.           o If locking multiple cbases, deadlock must be
  51.             avoided (see The cbase Programmer's Guide).
  52.  
  53.