crash@tsc3b21.UUCP (Frank "crash" Edwards) (03/04/88)
From article <3591@cup.portal.com>, by itkin@cup.portal.com: > I've been following both Frank's and Mike's adventures in Unify support > (or lack thereof). I've waited for Frank's latest (maybe last) above so > that I'd have all the information that he was going to post before > responding. > > First, congratulations to Frank on having his problem resolved, albeit > with great delay and frustration. Sometimes you just have to hang on > until the tiger drops. > > Second (and more)... > > I've been working both with Unify Corporation (since they were NAT) and > Unify and ACCELL for over five years. I can comfortably say that I've > been through experiences similar, if not identical, to most of the Unify > customers there are. I've also delved into the source code (legally of > course) and made some modifications to it. I've been through the > evolution of their support organization (it used to be one of the > cofounders, interrupting his engineering work) and the corporation. I > mention all of this not to brag or bore, but to establish (I hope) some > credibility. ^^^^^^^^^^^ Granted. > I understand Frank's frustration. I must say, however, that Unify > deserves a bit of defense. Their product DOES live up to its > advertising. Unfortunately what Frank ran into is a limit NOT in the > software but in the released version of the data dictionary (unify.db). > Unify DOES support 255 relations (tables) and 255 fields per table. I > know - I've looked at the code and in fact developed applications that > pushed those limits. The problem is this: unify.db is a Unify database > and must have expected counts set just as other databases do. At some > point, Unify decided to set the expected counts for tables and fields at > an arbitrary number (arbitrary to those of us who were not there). The > fix for Frank's problem (and Mike's), as they mentioned, is to > reconfigure unify.db (or have Unify do so). Unify finally twigged to > this and provided the capability in the released product. Why, you ask, > didn't they just size it to full capacity initially? Probably > considerations for space and performance. Unfortunately, I do not know > the exact reason (yes, I've dinged them about it too). So, in essence, you've had this problem -- and how was your support? As I mentioned in my last posting (I think I said it, anyway ;-), the Unify database works well; I/we have no problem with it. But... it was the support that threw me for a loop. We were in a situation frought with deadlines and commitments; we just couldn't wait (it seems it's always this way). And it seems it a little nit-picky to say, "Unify DOES support 255 relations (tables) and 255 fields per table" but then admit that the problem is the data dictionary. Granted they are NOT the same thing, but do you really think that matters? A limitation is a limitation. > As for the support person to whom Frank spoke who advised him that Unify > would only support 128 tables... Some people don't read everything or > remember everything. As I said, I KNOW that Unify lives up to its > advertising and can therefore only surmise that the support technician > was new with Unify and wasn't sure of his facts. Perhaps the technician was correct. I believe what I said was that the tech said only 128 tables were supported "as shipped". This indicates that it is/was configurable. 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 two weeks in advance, and schedule to have a new data dictionary sent to me. Or if "scom" had just bombed out! At least I wouldn't have mangled my data base (file.db) trying to find out what the problem was. > I'm also sorry that Frank was compelled to upgrade to Unify 4.0. While > I heartily recommend doing so, no customer should be forced to do so in > order to get what they thought they'd paid for. Again, I believe this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Exactly. That was what started this dicussion-turned-tirade (much to my embarassment, actually :-). > to be inexperience on the part of the support technician. I had the > problem corrected for me as early as Unify 3.1, so I know that they had > the capability to correct the problem before 4.0. Yes. In fact, when we reached about 900 fields with Unify 3.2, they shipped us out a new dictionary, configured for about 1800 fields, in a *very* timely manner. Supposedly, this new dictionary had the table limit increased beyond 128. I guess not... > Well, enough Unify boosting for tonight. Let me just close be saying > that I've had great success working with Unify and Unify Corporation. > It is a good company and good product and I recommend both unreservedly. > > Steven List > (formerly itkin@bene.UUCP, now itkin@cup.portal.com, next...) I must admit that the Unify product is perhaps one of the fastest database engines that I've worked with (which is a few on micros and a couple on super-micros). And both of my earlier postings were through red eyes. However, I would suggest that anyone that will be developing using Unify should use the 4.0 version. It has much nicer utilities, has increased information during procedures like reconfiguring, or doing a dbstats. (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 new tables to see if the dictionary needed to be reconfigured... I think I try that.) BTW: You said the software DOES support 255 tables. What do I have to do when we reach that magic number (right now we just hit 141)? Do I need to purchase source code and re-compile it with some #define set to more that 255? Or is it even possible? Thanks for concern, and I'm glad to know that there are other supporters of Unify. Keep in touch.
allbery@ncoast.UUCP (Brandon Allbery) (03/19/88)
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