crash@tsc3b21.UUCP (Frank "crash" Edwards) (02/24/88)
This is Part II of the ongoing Saga of One Customer's results
in Asking Unify to Support Their * Product * (Unify 3.2).
When we last left our hero, they were on the phone with "The
Company" trying to reach a solution to their problem of the distributed
software not supporting more than 127 record-types (which are referred
to as "tables" in Unify 4.0). As evening falls, the phone is still in
use, but there is a light on the horizon: Unify 4.0 will be shipped
to the customer (us) on the following day for only a small upgrade fee.
About 600 dollars small.
So finally the package is delivered via Fed-Ex two days later.
(No doubt Unify actually sent it out over-night.) Well, on Unify 4.0
the data dictionary is reconfigurable to support 'x' number of tables,
and 'x' number of fields. So far we haven't had any problems. And
since the $600 will be passed along to *our* customer ;-), we really
don't have a good reason to gripe anymore. Of course, if I were a
man of principle and integrity, who knows...
I suppose that our problem has been solved, but I'd like
to suggest a marketing strategy for Unify: don't exagerate the
abilities of your product. Of such makings are legal battles made.
And to the rest of the continent: "You's pays your money, and you's
takes your chances."
"The previous message was brought to you by ...
Bang-Bang. The sweetest little automatic in the world!"
-----
Frank (crash) Edwards ...!codas!usfvax2!{pdn,jc3b21}!tsc3b21!crash
TSC in Palm Harbor, FL Phone: (813) 785-0583 (voice)
The Sweat Shop
/-------------------------------------------------------------------------\
| These opinions are not those of my employer, his wife, either of their |
| children, or their parakeet. In fact, he probably doesn't even know |
| that I've said this! And I prefer it that way! |
\-------------------------------------------------------------------------/crash@tsc3b21.UUCP (Frank "crash" Edwards) (02/27/88)
In article <249@tsc3b21.UUCP>, crash@tsc3b21.UUCP (that's me!) writes: > When we last left our hero, they were on the phone with "The > Company" trying to reach a solution to their problem of the distributed > software not supporting more than 127 record-types (which are referred > to as "tables" in Unify 4.0). As evening falls, the phone is still in > use, but there is a light on the horizon: Unify 4.0 will be shipped > to the customer (us) on the following day for only a small upgrade fee. Their solution has so far been working -- Unify 4.0 is faster in most respects than 3.2 and does have more features. > [ .... ] Well, on Unify 4.0 > the data dictionary is reconfigurable to support 'x' number of tables, > and 'x' number of fields. So far we haven't had any problems. In conclusion, suffice it say that they *do* have a fast and reliable database manager. "This message brought to you by ... Bang-Bang! The sweetest little automatic ever made." ... From Star Trek: The Series, A Piece of the Action ----- Frank (crash) Edwards ...!codas!usfvax2!{pdn,jc3b21}!tsc3b21!crash TSC in Palm Harbor, FL Phone: (813) 785-0583 (voice) The Sweat Shop /-------------------------------------------------------------------------\ | These opinions are not those of my employer, his wife, either of their | | children, or their parakeet. In fact, he probably doesn't even know | | that I've said this! And I prefer it that way! | \-------------------------------------------------------------------------/
itkin@cup.portal.com (03/01/88)
> I suppose that our problem has been solved, but I'd like >to suggest a marketing strategy for Unify: don't exagerate the >abilities of your product. Of such makings are legal battles made. >And to the rest of the continent: "You's pays your money, and you's >takes your chances." >----- >Frank (crash) Edwards ...!codas!usfvax2!{pdn,jc3b21}!tsc3b21!crash >TSC in Palm Harbor, FL Phone: (813) 785-0583 (voice) 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. 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). 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. 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 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. 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...)
cory@upba.UUCP (03/06/88)
Just a little tid-bit of information should you need it...
It is possible to get into unify.db by calling it file.db[r]
and using SQL on it. We had to do this a couple of times when
we were first experimenting with the UNIFY users database and
security. (I accidentally locked myself completely out of the
database a couple of times, and there was no way else back in)
Just be warned, this is DANGEROUS for your database.
-Cory
...!ihnp4!upba!cory (Cory Dekker @ United Phone Book Advertisers)| DISCLAIMER:
Work: 1221 N St, Suite #800; Lincoln, NE 68508 {Ph: 402-476-2200}| My posting..
Home: 800 Foxcroft Ct, #188; Lincoln, NE 68510 {Ph: 402-483-7761}| MY opinions!friedl@vsi.UUCP (Stephen J. Friedl) (03/06/88)
In article <50500005@upba>, cory@upba.UUCP writes: > It is possible to get into unify.db by calling it file.db[r] > and using SQL on it. We had to do this a couple of times when > we were first experimenting with the UNIFY users database and > security. (I accidentally locked myself completely out of the > database a couple of times, and there was no way else back in) > > Just be warned, this is DANGEROUS for your database. To make this easier, copy SQL to another name, say USQL. Then run some kind of binary editor on it to change file.db[r] to File.db[r] (note capital 'F'). Then link unify.db to File.db and File.dbr and run USQL on the database. The above warning is relevant but possibly less dangerous than constantly changing and relinking your database name from unify.db to file.db and back again. Do you think Unify Corp. approves of this? many :-) -- Life : Stephen J. Friedl @ V-Systems, Inc./Santa Ana, CA *Hi Mom* CSNet: friedl%vsi.uucp@kent.edu ARPA: friedl%vsi.uucp@uunet.uu.net uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl
mike@cisunx.UUCP (Mike Elliot) (03/08/88)
In article <350@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: >To make this easier, copy SQL to another name, say USQL. Then >run some kind of binary editor on it to change file.db[r] to >File.db[r] (note capital 'F'). Then link unify.db to File.db >and File.dbr and run USQL on the database. The above warning >is relevant but possibly less dangerous than constantly changing >and relinking your database name from unify.db to file.db and >back again. Do you think Unify Corp. approves of this? many :-) >-- I've called Unify phone support and they have had me do things like that. Except they don't have you `mv' files around. You create a new directory and do your links from there. Mike Elliot {allegra|bellcore|cadre|psuvax1}!pitt!cisunx!mike mike@pittvms.bitnet It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage, than the creation of a new system. For the initiator has the enmity of all who would profit by the preservation of the old institutions and merely lukewarm defenders in those who would gain by the new ones. -Machiavelli
allbery@ncoast.UUCP (Brandon Allbery) (03/14/88)
As quoted from <350@vsi.UUCP> by friedl@vsi.UUCP (Stephen J. Friedl): +--------------- | In article <50500005@upba>, cory@upba.UUCP writes: | > It is possible to get into unify.db by calling it file.db[r] | > and using SQL on it. We had to do this a couple of times when | | To make this easier, copy SQL to another name, say USQL. Then | run some kind of binary editor on it to change file.db[r] to | File.db[r] (note capital 'F'). Then link unify.db to File.db | and File.dbr and run USQL on the database. The above warning +--------------- Under Unify 4.0, at least, it's just as easy to type: DBNAME=unify.db SQL (Under 3.2, you have to link unify.db to unify.dbr before doing this; Unify 4.0 only requires the raw file for raw database volumes, not for OS files.) And yes, this can be useful. (Especially with Accell if you want to change the menu label for an Accell application: execmnt can't do it, since they are all registered as index 0 in the coreload ACCELL, and changing it in the Accell/Manager doesn't seem to update the menus. The way to fix it is to do an SQL update on the "mpscrf" table.) Also other miscellaneous things can be done a bit more easily. And it is quite possible to design, using this alone, a procedure identical in effect to the "reconfigure data dictionary" procedure of 3.2c and 4.0 Unify. (Dump out the table and field definitions using SQL, then build an ordinary Unify database with these definitions and "crdb" it. Instant reconfigured data dictionary! "tnull" it to create an sunify.db for new databases, or dump the tables of an existing database and reload them into the new one, or copy the existing data dictionary to file.db in your reconfigure database and "scom" it with the larger size.) +--------------- | back again. Do you think Unify Corp. approves of this? many :-) +--------------- Seeing as how they do exactly this in the 3.1 to 3.2 conversion, I would guess that they do. It's also documented in the "Accell RDBMS Reference" manual (aka Unify 4.0 Reference). (They even list the output of the SQL "tables" ("records" for you 3.2'ers) command on unify.db.) -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery