Isam -111

I get error code -243, isam -111 in a stored procedure that executes a foreach select... loop (IDS 7.31 solaris 2.6_i86). -111 says: no record found. Why do I get this error at all, if there are no tuples that match my select, it should just do nothing, or perhaps return error +100. Does anyone know, why it returns -111 and what it really means? The foreach loop is executed in dirty read mode, could it mean that a record was just deleted by someone else? This would not be my understanding of dirty read, though. I am using dirty read precisely to be able to ignore changes done by other processes. --Micha

Micha Meier wrote: > > I get error code -243, isam -111 in a stored procedure > that executes a foreach select... loop (IDS 7.31 solaris 2.6_i86). -111 says: no record found. Why do I get this > error at all, if there are no tuples that match my select, > it should just do nothing, or perhaps return error +100. > Does anyone know, why it returns -111 and what it really means? No, no. The -111 is in combination with the -243 which says: "Could not position within a table..." and the RSAM library returned -111: "no record found". This means that the engine tried to resolve an indexed lookup but the rowid contained in the index node does not exist in the table. It means that an index is trashed, run oncheck -cDI on the table to determine which index but DO NOT let oncheck rebuild the index unless the table is small, it does not use parallel sorting and dropping the index and rebuilding it manually will be MUCH faster. This usually happens as the result of a crash on a non-logged database and sometime a buffered log database. It CAN happen to a buffered log database but it is exceedingly rare. > The foreach loop is executed in dirty read mode, could it > mean that a record was just deleted by someone else? This > would not be my understanding of dirty read, though. I am > using dirty read precisely to be able to ignore changes > done by other processes. Dirty read does not 'ignore' changes made by other processes it simply reads the current contents of the actual table without trying to acquire any locks and without trying to resolve uncommitted transactions which may be rolled back. As to could this be a row in the process of being deleted? Possibly, check the table anyway, especially if it happens more than just once. The circumstances that would allow this are very narrow, it is very unlikely to happen more often than the proverbial "Blue Moon" which occurs only a few times a year. Art S. Kagel