danny@itm.UUCP (Danny) (10/16/85)
Ok, as long as we're talking Unify, I might as well share some of my experiences. Overall, Unify is an adequate product, with few bugs, and one glaringly obvious assumption. As for speed, it seems a bit on the slow side, particularly for updates done via a C program and the supplied interfaces. I have written a specialized database application, whose update is: get a record (read a chunk of disk into a struct) play with the fields write it back out A Unify update works like: get a record (many different ways to do this) get a field (do this many times to get all the fields) change a field (many times too) put a field (update) Pfield, is a BIG mother. Does one of everything. Performs sanity checks, does locking, writes new field onto the disk. On the one hand, once you've done the pfield, the data is out there, period (aside from delayed writes inside the kernal). But the other side is: Consider the following pseudo-code: for (each record to be updated) for (each field in this record) pfield (field, buf) /* lock this record, update record, write to disk, unlock this record */ This is a *lot* of overhead, especially when one updates, oh, say 100 records with 50 fields each. Ok, let me partially absolve Unify. Our system is Version 7, which just recently gained the Bass kernal-locking stuff. In this version of Unify, it playes with a (shudder) lockfile. Of course, changing to kernal locking would speedup updates by a factor of 2 (maybe 3?). Throughout Unify, it assumes that there is only ONE printer, and that there is only ONE form on that printer, the correct one for this print job. So, what happens when finance wants to print an edit register on green-bar, print checks on check-stock, print a check-register, Jerry wants to print on letterhead, condensed, and I want to print shipping labels? Well, you resort to kludges, just like we did (if you *really* want it, I'll describe how we did it). Now, the bugs. We still occasionally have problems with the B-trees becoming corrupt, and we've had one record-type to completely barf big- time. To the point of: write the data into an ascii file, deleting the record-type, reconfiguring the database, re-creating the record-type, reconfiguring, checking the ascii file for weird chars, inserting the data, and it still weirds out (error in physrec, I believe). Even leaving the bad record-type in, creating a new record-type (same field types & lengths, different names) didn't help. And, as far as defensive programming is concerned, some do and some don't. As long as you give it just what is required, it works fine. But, if a parameter is neglected, or misplaced, instead of causing an error, it proceeds to try to process the data. Example: in checking the abovementioned ascii file for bad chars, we just deleted illegal chars with tr(1). Stupidly, I also threw away all newlines. When fed to DBLOAD, it tried to insert it. No complaints about too many fields on this line, line too long, or anything. Ok, I know that I screwed up, but I'm human, and DBLOAD *should* have caught it. Well, some of these are pretty picky, and I don't expect things like pfield to change. But, a way to specify printer and form would be nice for RPT scripts. And tracking down those last elusive bugs with the B-trees and screwy record-types would shut me up. I'm sure, now that this article is posted, that shutting me up is worth something. -- Daniel S. Cox ({siesmo!gatech|ihnp4!akgua}!itm!danny)