Path: utzoo!mnetor!uunet!husc6!ncar!gatech!mcnc!decvax!mandrill!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: comp.databases
Subject: Re: Unify 4.0 and the data dictionary
Message-ID: <7522@ncoast.UUCP>
Date: 19 Mar 88 00:36:39 GMT
References: <3591@cup.portal.com> <252@tsc3b21.UUCP>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.databases
Distribution: na
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 28

As quoted from <252@tsc3b21.UUCP> by crash@tsc3b21.UUCP (Frank "crash" Edwards):
+---------------
| My gripe is 1) why didn't the software warn me that the dictionary would
| only allow 128 tables, and 2) if the dictionary was the limitation why
| didn't the software at least just bomb out on me?  A fix for either of
| those would have been satisfactory.  Something like a message from "scom"
| (the reconfigure program) that says, "You've reached 90% of data dictionary
| capacity..."  This would warn me that I needed to contact Unify, at least
+---------------

It wouldn't be scom, it'd be schent... and to my knowledge a program using
regular Unify calls (Unitrieve) can't find out the "adjusted expected number
of records" AKA hash table size.  In fact, it may be stored in the data
dictionary, which leads you right back around to needing a master.db a' la
4.0.  (The error message is "No more space for record type <n>", where <n>
is whatever internal record type number stands for the "record" table in
unify.db.)

+---------------
| (In fact, maybe running dbstats on my dictionary would tell me what the
| current limits are.  That way I could periodically check'em after entering
+---------------

It might, but see above.  I suspect it'd get real confused when it looked in
unify.db to find out information about a record type in unify.db....
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
       {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery