Hi Over the past months we've seen a number of problems reported on this list that seem to relate to changes in the way that UniVerse is interpreting numeric/non-numeric fields.
Clearly .20 is numerically the same as .2, but they shouldn't be indexed together. If you do a LIST.INDEX, is it reporting the index as left or right justified? Brian Current problem. when selecting for another item, i get 2, one of which is the 'unselected' record that we have been looking for. BEEN USING SELECT FILE WITH INVOICE EQ "509010016.2" and get zero when no using NO.INDEX if I switch to another invoice number >ED FILE.INDEX 509010016.20 3 lines long. 0001: 01*261318*IN.509010016.20 0002: 01*261318*IN.509010016.2 0003: 01*261318*RF.509010016.2 Bottom at line 3. >SELECT AR.OPEN.B4 WITH INVOICE EQ "509010016.20" 2 record(s) selected to SELECT list #0. the two selected, first is number 1, 16.20 and the second is the one i want, # 2. --- Back in Version 6. I created several nifty indexes for the order file. Which had been designed to contain all orders, open or closed. by marrying the status flag to the custno, I created a unique enough key as to not bog down. Yeah, my first mistake was to create an index based on open or closed, which caused quite a performance hit. But by creating OPEN.ORDERS 001 = I 002 = IF STATUS = 'OPEN' THEN CUSTNO ELSE "" and create.index ORDER.DET OPEN.ORDERS NO.NULLS. I created a very useable index.. ditto when I swapped ORDNO for CUSTNO, so that the index was keyed by the ORDER NUMBER... But I haven't ----- Original Message ----- From: Charles Stevenson Date: Wednesday, March 4, 2009 4:45 pm Subject: Re: [U2] Universe Index not working To: u2-users@listserver.u2ug.org > In a prior release 10.0 or earlier, I encountered a problem that could > corrupt an index if a write was issued without an explicit readu > precedingit. I don't think IBM ever corrected that because > writing without explicitly locking is Bad Form. > If I remember, when process A holds a lock on a record and then > process B issues a write (w/o explicitly locking),by default B sits and > waits for 20 minutes, then gives up with a write error. (In my opinion, the > defaultlock.wait should either be forever, or a uvconfig parameter, not 20 > minutes.) > > If process B's write was to a file that had indexes, that > complicated things - I don't recall the details - and we ended up with > inconsistencies between the data files and the index files. > > How to proceed: - Monotor uv/errlog to see if you have write errors. > - Look for programs that write without locking. > - 20 minute wait limit is configurable. I set ours to one month > (=2678400seconds), effectively forever, since we'd bring UV down > & up more frequently > then that. To do so, execute a basic program from UV.LOGIN > (that all uv > processes execute on startup) that does ASSIGN 2678400 TO > SYSTEM(1999).TCL command SET.SQL LOCK.WAIT 2678400 > accomplishes the same. > > All that is from memory, by that's the gist of it. > > > Completely separate, but did you know you can create an F- > pointer to the > index file itself and then select, ed, basic open/read/write it > like any > other file? The F-pointer would look something like this: > F > I_FILE/INDEX.00n > D_your_debugging_index_dictionary_with trans()s to data file, etc. > > Sometimes that can help you troubleshoot or even manually > correct a critical > index on the fly. But be careful. You can easily introduce more > corruption. Especially if you leave the F-pointer lying around > after you're > done. > > Chuck Stevenson > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
