Re: Error -710: Table has been altered, rename or drop

On 12 Jun 1997, Telecom wrote about a -710 error: > Does enybody have some cues to fix this problem. The problem raise > ramdonely. To fix the problem presently, we rerun the stored procedure or > querie 2 or 3 times and finaly we get the result. We recently ran into a situation like this. It seemed to occur (twice) when we needed to add/remove an index on a busy production table (typical method, if they won't let us come down, is to run it a lot until it goes in). After the first execution, we'd get the -710 instead of the row-is-locked one. What's more frustrating is that all accesses to that table would return a -710 from then on. Cause: informix had a row-lock on the systabauth record for that table that wasn't associated with anything, and wasn't removed. Solution: Believe it or not, an UPDATE STATISTICS for that table removed the extraneous lock. Weird, but true. Bouncing the engine also seems to do the trick (what we did the first time). Informix response: Actually, they spent a great deal of time and effort trying to reproduce this one, which was nice. Latest guess is that it only hits multi-s, and our engine had only a uni at his disposal. Official wordL irreproducable. -Richard