Re: bad systable on SE 5.0

There might be a way to hack this further to get it back into a working state. I wouldn't do that however if you have any kind of important data in your database. With the kind of error you got you shouldn't even have tried the hack you did. I have done such things myself however, and understand the temptation to do it. I would spend whatever time it takes to rebuild the database. May be a simple dbexport/dbimport will do it. With that you may still have some bad data/tables, but they might be simple to fix. You should check the sql-script that is generated and remove any references to tables with tabid 246 and 312. It may of course be that the dbexport doesn't work, in which case individual unloads must be used. The hack I was talking about would involve creating a new database with all the same tables, indexes and so on. With that done you could copy the systables-file from that database to your current one at the Unix level and see if it now worked. There are *many* caveats. Another is to create a table in some database that is exactly equal to systables. Then insert every row from systables into that table. Then copy that tables .dat-file over the .dat-file of systables at the Unix level. This has even more caveates and would be likely to destroy your database entirely. If it doesn't do it immediately it may be destroied in a week or a month or whatever from now with no explanation as to why. Do *NOT* do any of these hacks for *any* purpose but to find data that couldn't otherwise be found and save it to Unix files. For such situations you have backups - use them. On Sun, 21 Jun 1998 19:31:16 GMT, axsander@okay.net (Axel Sander) wrote: >Hi, > >I just ran into the following problem: >(Sun OS 5.4, SE 5.0UC1) > >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 > >I could delete the syscolumns entries and the database file. bcheck on >systables said everything is ok but accessing the systables entry >failed (see log below). I can't delete the systables entry and >recreating the table is impossible, too. > >Is there *any* chance to repair the systable or must I spend my next >weekend on rebuilding the complete database? > >THX Axel > > > >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 > >1 row(s) retrieved. > >> >> select * from systables where tabid=246;> >No rows found. > >> >> delete from systables where tabname="buchen";> > 240: Could not delete a row.> > 111: ISAM error: no record found. > Error in line 1 > Near character position 43>> > >-- >This is the automatic signature replier. The current signature >is on vacancy. Please leave your login ID and password. THX Nils Myklebust NM Data AS Norway E-mail: Nils.Myklebust@nmdata.com FAQ at: http://www.iiug.org/techinfo/faq/faq_top.html (Now with ODBC info under "Third party products".)