brown@hpccc.HP.COM (Jeffrey L. Brown) (12/22/88)
/ hpccc:comp.dcom.lans / agollum@engr.uky.edu (Kenneth Herron) / 1:27 pm Dec 18, 1988 / > Hello, > > Our company has this application, written in clipper (autumn '86 version). > One of its data files is giving us trouble. The file in question is small; > usually between 10-40 records of 7 fields each. There are two indexes, > one based on a single field and the other based on two fields joined > together. > > The problem is that this file simply refuses to stay indexed. It is used > rather heavily by portions of the program so records may be added, changed, > & deleted several times per minute. In addition one portion of this program > scans the file in question every time it is changed to update a screen > display. In addition the program is networked (via Novell Netware 2.0a) > so as many as four stations may have the file open at once. > > Reindexing the file will only last about 15 minutes or so, then we get > the dreaded 'Index error rec !in ntx (Q/A/I)'. That's right, '!in'. > If we [I]gnore that error we get 'Index error update'. The line in the > source code where the error occurs is an unlock following several > REPLACEs. We occasionally get similar error messages at another unlock > statement. We never get errors while simply reading the file. We have > also never had ANY kind of error with other files for this application-- > just this one. > [text deleted...] > > Does anyone know of any bugs in this version of clipper which affect > index files? Does anyone know of any bugs in this version of Novell which > affect record locking? How could the program be mangling its index > files, assuming that they were opened properly? First, Don't Panic (where's that guide?...) Second, more info on the file's environment is needed. Are there any relations set into this file or from this file? What are the exact index expressions? What are the lengths and types of those fields? How are records being added: append blank followed by replaces? directly entered by the user (though probably not, sounds like this is a status-tracking file to me)? Third, I was able to work around this thing (don't you just love that message!), so this thing isn't insurmountable. I fought this guy when using s'86/2.0a in my previous job. Having relations around during the record update thrashed any index involved with that field. I never had this problem with the 87 (winter 87 I think, it's been several months...). Granted, this may not be what's happening at all. I do know that 86 indices are extremely fragile, while 87 are not (An aside: upgrade to 87--it's definitely worth it! All kinds of neat stuff!! And lots of the stupid things in 86 are fixed or significantly improved.). I do know that the 87 version does NOT use netware's locking services to do locking; Clipper handles it itself. I assume 86 is the same way. We preempt your regular programming... Oh, a warning to anyone who happens to use '87 in a Netware 2.1x SFT environment. I wrote a simple C package to let me use the transaction tracking system (TTS) in Clipper (another aside: TTS is another one of those protection gems that really works well. Kudos to Novell for an excellent job). Assume you have a transaction in progress which updates a file. That file is indexed. Therefore, Clipper throws out its own lock on the index. From that point on, the file and its active indices are UNAVAILABLE to all other program users until the transaction is closed!! Anyone else who is using the program will get a "dead screen" while the pc waits for access. This is because the server doesn't release that lock until the transaction closes. Moral: keep transactions as short as possible, and NEVER, NEVER, NEVER have any user interaction inside a transaction. Back to the real world... (the dreaded) disclaimer: I USED to do PC programming (Hi Paul, Mike and Merril!). I have no affiliation with Nantucket or Novell (other than as a past user). As I don't get here often, e-mail is probably faster.... From the soapbox (hey, what's that guy doing with that tomato!) Jeff Brown HP Corporate Computing Center brown@hpccc.hp.com ...hplabs!hpccc!brown