Re: Recommended Books etc

In article <9114@emory.mathcs.emory.edu> Steven.J.Richardson@um.cc.umich.edu writes: > Allow me to venture some suggestions for the manuals: > > 1) Make more & better examples which illustrate some of the > more powerful or non-obvious ways of using the commands. The > current examples are essentially worthless. This has been a consistent request from every user we've talked to (and we have a regular program of talking to users of manuals). It was as a direct result of this user feedback that we produced the voluminous "4GL By Example" and the many, detailed and copious examples in the two-volume set "Informix Guide to SQL: Tutorial" and "Informix Guide to SQL: Reference." Examples in early manuals were indeed thin. If you are describing your experience with manuals of 4.0 vintage and earlier, please take a look at the newer books. > 2) In my experience... most Informix > manuals hint at what knowledge is needed, but is not really > present, and are more overview manuals aimed at persons who > don't know very much and don't wish to become experts, rather > than those who really wish to become well-versed in the use > of Informix. My personal opinion is that, with respect to earlier manuals you are correct in spirit tho wrong in the letter. Everything really is in there (and I speak as a constant user); but those manuals are (again, IMO) weak on pointing out connections, implications, and in giving context. However, we have tried hard to upgrade all of these aspects in more recent efforts; also the staff of writers is getting ever more knowledgeable themselves. If there's an interesting or important fact that you cannot find in a manual for a current-level product, let us know (see below). > Indeed, it seems that this feeds the courses > which Informix offers, since there appears to be a bit of > information which is quite generally useful that one is > told/given in the courses, and which would normally be found > in a good manual. This is not a conspiracy; it is the result of the Training and Pubs departments being separate, writing for different audiences, but on parallel schedules with tight deadlines. There often simply isn't time to coordinate. The Training writers tend to concentrate on developing good hands-on exercise material, so their examples have in the past been better (they also have the advantage of being able to display complete programs, which manuals can't normally do). Students get the benefit of guided, hands-on exercises with an instructor and other students to answer questions. So there will always be an advantage to training over manuals. But if you get a fact from a training course that is NOT documented in a current manual, let us know; it's a bug and we'll fix it (see below). > 3) Information is only half the battle; getting to it is > important, too. The Informix indexes don't address every > concept, etc., and so are incomplete, making it harder to > find a specific reference. After "more examples," the #2 demand at every user interview and site visit used to be "better indexes." Again as a direct result of user feedback, starting with version 4.0 we made a massive assault on indexes. One major improvement in the 4.0 manuals was a literal doubling in the physical size of the indexes, which represented a quadrupling of the entries since they were printed 2-columns instead of one. There is still room for improvement; indexing is a never-ending task. If you look in an informix index for some topic and don't find it -- and later find the material despite this -- please let us know (see below). > 4) Undocumented functions/features that are generally > useful are another weak point. For instance, a local p > programmer was told about an Informix function which tells > you the names of all known databases (for a given engine, > perhaps for a given dbspace), which is obviously useful. Undocumented functions are undocumented for a good reason: because they are not *supported*. To put a function in the manuals is to create an implicit commitment of support and continuity over later releases. You can find out about lots of undocumented functions. You use them at your own risk. > Thanks for asking, > Steven J. Richardson, > Merit Network, Inc. Thanks for your comments. I would like to point out to you and any other dissatisfied readers, you do not have to stew in silence. First, there is a postage-paid reader comment card in ever book. We really do save these, read them, summarize them, and heed them. Second, when you note *specific* errata (missing/wrong fact, missing index entry, etc), get the info to us any way you can. Tech support knows how to notify us of errata. Or you can send such *specific* (please) comments by email to doc@informix.com.