1. <<snip> only necessary to rebuild the index(es) when you have a known corruption issue. <<snip> Management decision from a long time ago and it is our comfort level to continue. I agree in principal with not rebuilding, but do not have 100% faith in any technology providing 100% reliability. 99.9% is sometimes not good enough. When clients are relying on us to provide their financials via web reports on a timely and accurate basis that .1% could lose us a big client and lots of money if it was wrong.
2. BAD.ADDR <<snip>> used in selects as a true/false flag. 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: [email protected] 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 [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
