🚀 go-pugleaf

    The  following  is  written  in  response  to  the  article  posted   by
    steve@tellab3.UUCP.    That  article,  <293@tellab3.UUCP>,  contained  a
    locally written memo by Michael Skowronski lambasting UNIFY.

    We have been using UNIFY here at Benetics for  over  three  years.   Our
    relationship  with  that  company goes back to when they were just a few
    people with a  relatively  new  product.   During  the  course  of  that
    relationship we too have had our complaints.  However, I feel that UNIFY
    provides the best performance and capability of any dbms on  the  market
    for our needs.

    I would like to respond to Michael's points in order  (although  perhaps
    not all of them).

    "The first major bug...record locking scheme...just does not work."   He
    alludes  to  colliding  when  READing records.  Who cares if you collide
    when reading?  The locking is for concurrent updates, right?  I guess it
    does  matter  if you are doing a read before update.  Our experience has
    been that we have never, to our knowledge, had such a collision.

    "...UNIFY does not check itself when attempting to access a  record...".
    There are two problems here: what does Michael mean by "access" and what
    does he mean by "check".  UNIFY  does  check  that  the  application  is
    accessing  a  real  record when the acckey(), seqacc(), and other random
    and sequential functions are used.  A return value indicates the success
    or  failure of the call.  If, however, the programmer ignores the return
    value and proceeds to attempt a gfield(), UNIFY will indeed exit because
    there is no current record when an access fails.

    I too complained about the manner in which UNIFY exits when encountering
    what  they  treat  as  an  unrecoverable  error.   However, upon further
    experience, I found that their exits were appropriate.  The major change
    we  made  (via  reading  their documentation) was to replace their error
    routines with our own that do a core dump (a process kills  itself  with
    an EMT signal).

    In Michael's section on "Implementation  drawbacks",  my  impression  is
    that  there  are  some valid gripes, but they are all minor and at worst
    irritating.  There is one error in his statement: he says that there  is
    one routine to read the first record in the database and another to read
    all of the others.  This is not so!  Both routines are seqacc(),  but  a
    different  argument  is  passed  to indicate FIRST, NEXT, PREV, or LAST.
    This is a very reasonable approach.  The only drawback that I can see is
    that it would be nice if NEXT meant first if the record type has not yet
    been accessed.  Hardly a major inconvenience.

    Finally, there is "Poor  Implementation  and  Support".   I  am  totally
    confused  by  the  statement  that  "Many  of  the routines supplied for
    sorting and searching just don't work as documented.".  I  have  written
    several   programs  that  use  the  sorted  sets  and  they  work  quite
    successfully.  I have not used unisel and several  other  facilities  so
    cannot comment on them.  I do suspect that Michael has some program bugs
    that he is attributing to UNIFY.  I will make an open offer here to help
    clarify the problems.  While I have no vested interest in UNIFY or their
    products, I do have believe that the product is  good,  getting  better,
    and worth defending.

    As for the support provided by UNIFY, I too have my complaints.  I  have
    found,  however, that the support personnel are always willing to listen
    and attempt to resolve a problem.  I have had problems  that  they  have
    been unable to reproduce.  I cannot fault them for not solving a problem
    that they cannot reproduce.  I do  not  solve  problems  that  I  cannot
    reproduce.
-- 
***
*  Steven List @ Benetics Corporation, Mt. View, CA
*  Just part of the stock at "Uncle Bene's Farm"
*  {cdp,greipa,idi,oliveb,sun,tolerant}!bene!luke!itkin
***