Solved Daily errors due to 'Unrecognized database format'

[Darrell]

Hey guys, I was just wondering if there is any update in regards to this issue as it's driving me crazy.

I have a simple db (using O365 on Win10) that really only has 2 users, me being one of them. I import text files into it regularly and part of that process creates a temporary table, adjusts the data accordingly (changes date formats / drops un-needed columns etc), moves the remainder into the relevant permanent table and drops the temp table. This has been working perfectly for the last 10 yrs.

What I've encountered over the last year or so is that quite often (especially lately) the temp table will not be deleted at the end of the procedure even though it ran without apparent issue. Then, when a new procedure is run and it checks to see if there is a temp table that needs to be deleted before it creates a new one, it throws this error as it now can't delete it for some reason.

Then I get the whole - 'Database is in an inconsistent state..' drama and it's all over from there. Once it has C&R (and presuming everything is still in one piece) the table can be deleted no problem.

Very frustrating...

 

[theDBguy]

Sorry to ask, but is your database split?

 

[The_Doc_Man]

To add to the list of questions, where (physically) is the database? On your terminal? In a shared folder? But theDBguy's question plays into this.

 

[CJ_London]

Also need to know if your db is compacted on a regular basis - creating and deleting tables causes bloat and you may be close to the 2Gb limit

 

[Darrell]

Thanks for the replies chaps..

OK so db is not split and resides on a shared network drive. It is also compacted on close ~ size is approx 175Mb

 

[theDBguy]

Thanks for the replies chaps..

OK so db is not split and resides on a shared network drive. It is also compacted on close ~ size is approx 175Mb

My first recommendation then would be to properly split it.

 

[Darrell]

My first recommendation then would be to properly split it.

Right - it's split, I'll see over the next day or two whether this has helped I guess. Cheers

 

[theDBguy]

Right - it's split, I'll see over the next day or two whether this has helped I guess. Cheers

It should, even if not for the problem that brought you here. It definitely helps. Good luck!

 

[Darrell]

Well that didn't work - I've now got an error stating that 'ID is not an index in this table' and it seems quite irrecoverable.

I will have to get our IS guys to restore from backup and re-think what to do with this.

 

[theDBguy]

Well that didn't work - I've now got an error stating that 'ID is not an index in this table' and it seems quite irrecoverable.

I will have to get our IS guys to restore from backup and re-think what to do with this.

Sounds like you got a different error this time. When you split your db, did you give each user their own copy of the front end?

 

[Darrell]

No - I was still in test mode and hadn't even had the chance to do that before I got this error. Would it cause an issue if it was accessed during this time..?

 

[theDBguy]

No - I was still in test mode and hadn't even had the chance to do that before I got this error. Would it cause an issue if it was accessed during this time..?

Were there more than one user using the same FE at the same time?

 

[Darrell]

Possibly yes.

EDIT: OK make that a firm yes, just spoke with the guy and he'd been in it. Oh well, that's one way to learn

 

[theDBguy]

Possibly yes.

EDIT: OK make that a firm yes, just spoke with the guy and he'd been in it. Oh well, that's one way to learn

Hi. Properly splitting a db doesn't eliminate all problems, but it does get rid of a lot of them - corruption being one of the usual ones.

 

[Darrell]

Yeah I guess I'll have to read up on how to do it properly as I've not needed to do it before.
Thanks though.

 

[theDBguy]

Yeah I guess I'll have to read up on how to do it properly as I've not needed to do it before.
Thanks though.

Okay. Good luck!

 

[isladogs]

Well that didn't work - I've now got an error stating that 'ID is not an index in this table' and it seems quite irrecoverable.

I will have to get our IS guys to restore from backup and re-think what to do with this.

That error usually indicates corruption in a system table. See this link for a fix http://www.datagnostics.com/dtips/fixaoindex.html

 

[Darrell]

Thanks Colin, certainly seems that way. Have restored from backup now, running OK and looking at plan B which is doing something else other than creating and deleting temporary tables.

 

[isladogs]

From experience, repeatedly creating & deleting temp tables will lead to instability and result in exactly the message you have been seeing.
However you would be advised to avoid doing that. Much better to populate & empty the 'temp' tables rather than create & delete

In the meantime, decompiling will provide a short term fix until you can redesign your application

 

[Darrell]

Just posting an update so as to mark this as solved.

After having daily problems with this error I applied the Registry hack on my PC listed in this website in December and have had zero problems since.

Much relief...