Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site luke.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!oliveb!bene!luke!bob
From: bob@luke.UUCP (Bob Speray)
Newsgroups: net.database,net.unix,net.micro.pc
Subject: Re: Unify Database Problems
Message-ID: <340@luke.UUCP>
Date: Wed, 9-Oct-85 20:59:43 EDT
Article-I.D.: luke.340
Posted: Wed Oct  9 20:59:43 1985
Date-Received: Sat, 12-Oct-85 15:26:11 EDT
References: <293@tellab3.UUCP>
Reply-To: bob@luke.UUCP (Robert Speray)
Organization: Benetics Corp, Mt.View, CA
Lines: 88
Xref: watmath net.database:97 net.unix:5850 net.micro.pc:5551
Summary: 

In article <293@tellab3.UUCP> steve@tellab3.UUCP (& Harpster) writes:
>
>The following is a memo written by a co-worker describing the problems
>we have found with the Unify database system.  I thought it would be
>of general interest.

The quoted memo was a real indictment of the Unify dbms product.  
"Problems with Unify", "major flaws", "irritating bugs".
Its tone was -massive troubles with that Unify system-.

This response is to balance the thrust of the original memo.  
Unify does not have the "major flaws" that were claimed.

record locking?  WHO has this problem solved on Unix?  Every variant
solution around has its limitations.  Unify uses John Bass locking
in our environment( Plexus P60, sys3) - an absolutely exclusive lock that
locks out reads as well as writes.   It works fine, AS DEFINED, but
has severe limitations on concurrent reads.  It's ok for concurrent writes.

Unify not checking itself?  I think this describes the documented misuse
of access/gfield.  You request a record by key without checking the
return code, then attempt to get data out of the record.  The gfield
call aborts because there is no record to get data from.  You want Unify
to check that the record exists at the gfield call and return an error
code to you then.  You didn't look at the return code after the access.
You've got an application bug.  

poor error recovery?  Unify returns error codes for recoverable errors and 
exit(99)'s on non recoverable errors.  We had a similar criticism but learned
that non recoverable errors were of two sorts - corrupt database or
application program error.   Both type errors should disable continuation
of a process in a production environment.  Unify does define a way to load
local error handling routines but they should never return, only exit.
Our error handling routines produce a core dump on the way out.

underscores in field and record names?   A real bug.  Supposedly fixed
in the latest release.

no b-trees on combination fields?  Yup, just as defined.  A limitation
of course.

limit of 9 digits in numeric fields?  Only on display, using Unify screen
utilities.  The data is stored as a long and contains valid values.
This display limitation is a bother. 

different calls for reading first record and for reading rest of records?  
This observation is similar to the observation that Unix defines
different calls for opening a file and for reading it.  
Is this a valid criticism?

records stored in random order?  I don't understand this point at all.
The phrases, "long delays when searching back in time", must refer to
a particular function that takes a long time to run.  I don't see the
connection to record storage strategies.

sorting and searching routines don't work?  We use some of the sorting
and searching routines and have no trouble with them.  A simple test
program that doesn't work properly demonstrates a bug in Unify or 
a bug in the application.  Seems straightforward to discover the fact
of the matter.

you claim you've discovered a bug in the Unify record locking implementation?  
and Unify support wants to see your test program in order to duplicate 
the problem? so what's the issue?  "ha ha, i found a bug but i wont help 
you fix it cause you don't think there is one."

poor support?  Sounds more like a personality conflict.

I'd prefer support persons who are highly qualified
programmers, intimate with the coding details of the system, and anxious to
find bugs in the system and correct them, but I'll accept someone who
listens to my problem,  conveys the problem to the development staff,
and follows through with a recommendation to me on how to continue.
Our interactions with the Unify support office have been adequate.

Are there real problems with Unify?  We have been using Unify
for several years now in a complicated multi-user application.
We have discovered some unusual aspects of Unify but have been 
relatively happy with the product and the support. 

In fact Unify provides the best dbms product in the Unix
market for our application, by far.  We have 150+ record types
in our schema, 200Mb of data, and a stringent response time requirement.
Other vendor products might be ok for other applications but none I know of
can provide this capacity or performance.

Robert Speray
Benetics Corp