Inconsistent .bi and .db

[Vaalen]

We have a customer with around 15 progress databases, using v7 to start and stop them. Clients use v8.3 to use them..
Starting and stopping the databases has never been a problem but recently 11 databases seem to have problems.

Databases are shut with an 'unload _mprosrv' command. Personally, I thought that should be a proshut command, but that seemed to work fine for years.

About 11 db's have before image files with a different timestamp. The creation dates are ok, but the .bi files are updated after the db has been shut down. In most cases the difference is about 4 minutes.

So, those database are down and the cannot be starten. I tried a probkup/prorest but even probkup won't work.

Are there any suggestions on how to handle this?

Our customer uses a novell network with windows clients.

 

[TomBascom]

You're screwed.

Restore and roll forward your after-image logs.

And get off Novell.

You need to upgrade this system yesterday.

 

[Vaalen]

Thank you Tom, but that's is not my decision to make. The customer makes it's own choice....

Unfortunately there is no backup and no after image. Just a before image file.

 

[Casper]

Well, then like Tom siad --> you're screwed.
Only way left is to force your way into the database and dump the data.
Read the excelent answer Tom wrote last week in a thread with someone who had his bi files deleted: http://www.progresstalk.com/showthread.php?t=112232

I think this is a good point for the customer to realise that having there environment the way it is is much much more expensive then to invest in a decent OS with a recent version of Progress. The database is not garanteed to be consistent anymore.
Furthermore I think it's the application vendors responsibility to point out that it is absolutely nessecary to make regular backups and always enable AI on a prodcution database. Unless they really don't care about there data I can't find any reason not to have a decent bakcup strategy. I know that the customers decide, but I guess it all depends on the choices you give them to decide about.

Regards,

Casper.

 

[Vaalen]

Thank you Casper. You are right, but this particular customer is not willing to change anything.

But, I managed to force myself a way into the database, using the commands from the missing .bi-files link. After that I was able to dump the database and create a new one.

So for now this will do, the customer knows that there the problem may occur again.

Thank you for your input.

 

[rhi]

Thank you Casper. You are right, but this particular customer is not willing to change anything.

Then shake his hand, wish him luck and move on. Anyone this stupid deserves to loose their data. V7 was retired a long time ago, and V8 might be depending on your OS.

 

[rhi]

Unfortunately there is no backup and no after image. Just a before image file.

Let me correct myself. Very, very stupid.

 

[TomBascom]

V8 has been retired for a very long time as well.

Version 9 has also been retired, for all intents and purposes, for several years. Version 9.1e04 was the last release of v9. There will be no more service packs for v9. No bug fixes. Nothing. All you'll get for "support" at this point is a sympathetic ear.

It is way past time to move to OE10.

 

[TomBascom]

Thank you Casper. You are right, but this particular customer is not willing to change anything.

But, I managed to force myself a way into the database, using the commands from the missing .bi-files link. After that I was able to dump the database and create a new one.

So for now this will do, the customer knows that there the problem may occur again.

Thank you for your input.

You should make sure that your customer is aware that even though you may have dumped and loaded their database (which would have been the ideal time to upgrade them...) that they still very likely have subtle data corruption. Forcing the database throws away valid data and does it in unpredictable ways. Yes, sometimes you "get away with it". But there is no way to know, for sure, if you did or not and it may be months before serious problems surface.