says...
Quote:
> Hello!
> I have a problem: we have two environments on our aix-system. 1 a 6.3f
> and 1 a 7.3, what has happened is that a deveoper started the
> 6-database with version 7, discoverd what he'd done, deleted a .lk
> file and restarted the 6-database with version 6. Now months later, we
> stopped the system for maintenance and when tried to restart the
> 6-database we're unpleasantly surpised with the message that the .bi
> file refers to a database last used on the day that the above error
> was executed. Is the a way to fool the bi image file to refer to the
> current database? Otherwise we lose a whole day's production.
> I hope I have described the problem clearly as I'm not the
> administrator!!
> thanks for any input (even bad news!!)
You're in trouble.
You can do a "mock index rebuild" to recover from the obvious symptoms
but you will lose data. The problem is that you have no way to know what
data... Your best option is to restore from backup.
Trust me, that really is the best thing to do.
If you don't trust me then use the -F option to force access to the
database (if you're lucky you'll only spend months cleaning up relational
integrity issues as they pop up out of the blue...) and then use proutil
to do an index rebuild. When proutil asks you what indexes just use "!"
to say that you're all done without actually selecting any. It'll run
through a few steps and then quit after clearing the "tainted" flag.
You will lose data. You won't know what data until you trip across it.
BTW, if that 7.3 release isn't 7.3e you should patch it immediately.
7.3a and 7.3c01 in particular are very, very {*filter*} releases to be
trusting production data too... And 6.3 is obviously prehistoric...