Re: bad systable on SE 5.0

+On Sun, 21 Jun 1998 19:31:16 GMT, axsander@okay.net (Axel Sander) +wrote: +>I dropped a table "buchen" and recreated it. Accessing all other +>tables was ok but after getting problems with this table I figured out +>the following: +>* the original systables entry with tabid=246 was unchanged +>* the database files had a (new) extension of 312 +>* the syscolumns entries had changed to a tabid of 312 <snip> +>informix>dbaccess spross - +>> select * from systables where tabname="buchen"; +> +>tabname buchen +>owner sptest +>dirpath buchen_246 +>tabid 246 +>rowsize 104 +>ncols 18 +>nindexes 0 +>nrows 239837 +>created 17.01.98 +>version 16121991 +>tabtype T +>audpath Nils.Myklebust@nmdata.com (Nils Myklebust) offerred: +There might be a way to hack this further to get it back into a +working state. Indeed there is. One of the nice things about working with SE is that it is so easy to hack & repair. In this case, running as user informix: UPDATE systables set (dirpath, tabid) = ("buchen_312", 312) where tabid = 246; Since Axel indicated that all the entries in syscolumns already had a tabid of 312, that *should* do the trick. Of course you need to be sure that there are no other entries in the system tables referencing tabid 246, else there could be other problems. But as long as systables is the only catalog affected, the above shoudl work fine. Note you do need to be user informix (only informix can update the system catalog tables). If you like, afterwards you could run CHECK TABLE buchen; to be sure it is honky-dory. The big question is WHY did systables get into such a state? Dave ** Dave Kosenk <davek@summitdata.com> ** Director of Training Services (732) 469-4070 ** Summit Data Group (an Informix Authorized Education Center) ** Find my advice useful? Let me teach you everything I know about ** Informix. Sign up for OFFICIAL Informix training at SDG. ** For details, see http://www.summitdata.com/training