*BAD* data in table

We have a nasty problem with 4.1 Informix Online, running on a Pyramid MI server. A while ago, we inadvertantly overflowed our lock table. This caused much data in the partition to be munged. We especially are having problems with our tables that have rows over two pages (Informix claims row may be as big as 32k bytes). Our row size is 2334. That aside, I have two VERY STRONG points to make to you all. 1) NEVER overflow your lock table, or *bad* things will happen. We blew it because we didnt realize that a lock is created for each key (ie. 10,000 rows, 3 keys, 30,000 locks). When the lock table overflowed, it tried to rollback, but rollbacks need locks, so it barfed (sigh). At the very least, Online should have immediately been forced to quiescent. In the future, they are discussing having a configurable switch in tbconfig that specifies you want Online taken down in this instance (which was detected as a bfcheck Consistency failure in the logs). 2) For the time being, do not use rows in a table larger than 2041 bytes. We have uncovered some serious problems, and believe there are still more. 4.1 Informix is better, but there are still problems. Now to my question for you. Due to some of the above problems, we have some garbage rows in some of our tables. We (and Informix) have not been able to come us with a method to detect which and how many rows are bad, and, what to do with them when we find them. If we create a form and query all rows in the table, when we page through the rows, we can see which rows are bad. We cannot, at that point, delete or update these rows. We get bogus error messages back complaining "someone else had deleted something in your list". If we query a specific row with a form, it brings it up with garbage data. If we use query language or esql/c, it just cant find the bad rows. Unloading the table blows up with nasty messages about bad data. Using a sql statement that select from one table and insert into another seems to drag the garbage along. The overall question is, why can forms find the row when sql cant, and how can we use that fact to help us? I would have thought forms ended up using sql statements, but have seen from experience that it is much more forgiving than straight sql. Comments anyone? -- Naomi Walker (aka N7FSA) Anasazi Inc. Phoenix, Arizona 602-395-1731 {uunet!syntllct},{asuvax} !anasaz!naomi