If I remember correctly, and tell me if things have changed, indexed I-descriptors and correlatives that do translates from other files do not update indexes. This is one reason for building indexes periodically.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ballinger Sent: Tuesday, February 06, 2007 3:59 PM To: u2-users@listserver.u2ug.org Subject: Spam:RE: [U2] Index Problem Hi Brenda, 1. It is probably only necessary to rebuild the index(es) when you have a known corruption issue. I think all indexed fields (I-type or not) are (re-)evaluated with every write; U2 indexes are self-updating. 2. If BAD.ADDR is just used to identify bad addresses, consider changing the I-type to return either 1 or null, and create the index using the NO.NULLS option? 3. However, does the BAD.ADDR field exist for selecting and totaling? Else why not just index the BAD.ADD field itself? It's probably marginally faster to build/maintain an index on a "real" field than on an I-type field. OT question for the list: is the practice of rebuilding indexes (nightly?) common? Why? I use a lot of indexes on large and active files, and very rarely have to rebuild them. Rebuilding indexes on a periodic basis looks like a little too much of the belt AND suspenders mindset. Are the U2 databases really so un-reliable that we have to resort to these sorts of hacks? (Actually, IMO they are very reliable and no you don't.) /Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brenda Price Sent: Tuesday, February 06, 2007 10:38 AM To: u2-users@listserver.u2ug.org Subject: [U2] Index Problem Last night a process that sleeps until around 2-3 am, then wakes up and does a BUILD.INDEX CUST.MSTR ALL failed. One of the indices BAD.ADDR was locked and failed which stopped all the other indices from building. So when we came in this morning nothing had been done from that point on. I've changed the process to build each index one at a time instead of the ALL option, so if one fails the rest continues, which will slow it down somewhat but is safer. Plus only the indices that are correctives will be rebuilt. This happened before in May 2006 and I am pretty sure that it was the exact index (BAD.ADDR) that hung us. The dict is this: BAD.ADDR <1> I <2> IF BAD.ADD = "Y" THEN 1 ELSE 0 <3> <4> <5>1R <6>S BAD.ADD <1>A <2>44 <3>Bad^253Add <4> <5> <6> <7> <8> <9>L <10>1 On our test system, I've changed BAD.ADDR, deleted the index, created the index, and built it again as I was wondering if it was having problems from using another dictionary item. Once a window of opportunity happens I'll do the same on our live system. <1>I <2> IF @RECORD<44> = "Y" THEN 1 ELSE 0 <3> <4> <5>1R <6>S No one really thinks that is going to matter but I'm grasping at straws. Any ideas? Brenda Price Affiliated Acceptance Corporation Sunrise Beach, Missouri ------- 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/
