X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
   Reply to this topicStart new topic
> Id Is Not An Index In This Table Error, Access 2013    
post Jan 10 2017, 09:22 PM

Posts: 247
Joined: 15-December 16

Hi all,

I went and broke my DB. [censored] it! So now I have the above mentioned error. I can no longer properly access my database. I've tried:

* Compact and repair - did not resolve and also produce multiples of the same error.
* Creating a blank DB and tried to copy forms and queries. I managed to import the tables and queries, however, the forms, macros and modules cannot be imported.

I have heard that a DB can be recompiled manually, but don't know how to do it.

How can I solve this issue. the problem occured while copying a backup into my working directly and it lost the backup, so yeh: problem warrants a bullet in my brain if I cont solve it. Does anybody have any ideas?

Go to the top of the page
post Jan 10 2017, 10:29 PM

UA Admin
Posts: 32,842
Joined: 20-June 02
From: Newcastle, WA

There are several things to consider here, but first things first.

You have the crucial objects, i.e. the tables with your data. The rest can be recreated, albeit not without effort.

I take it from the description that you had only one accdb, and that there are no other backups available. That needs to be rectified as soon as possible, but the immediate need seems to be to try to recover some of the forms and reports. I don't have high hopes for that, but you could try the undocumented SaveasText and LoadFromText actions in VBA. No guarantees, but it is worth a try.

Before you do anything else, create a backup of what you do have. Recovery efforts might not help and could make it worse.

For future consideration, there are two or three important lessons to be learned here.

First, it is a well-established best practice to separate all Access databases into a Front End accdb containing only the interface objects (forms, reports, code, etc.) and a Back End accdb containing only the tables. The back end can be linked to the front end.

Second, regular backups are also a best practice. I'd recommend at least once a day, and during development far more often. Once an hour or even more frequently. Losing an hour's work is painful, but not as painful as losing everything.

Third, we don't really have a clear picture of how this backup copying failed, but some things that can be implicated would be copying--or trying to copy--an accdb while it is open and in use. Hopefully, that didn't happen here, did it?

Another problem that sometimes impacts Access is that it is quite sensitive to network connectivity, and especially to wireless networking. Again, if this backup was being copied via a wireless network, that could be behind the corruption.

So, at best, the SaveAsText and LoadFromText action MIGHT be helpful, and at worst you have the task of rebuilding the interface around the data which you have rescued.

Go to the top of the page
post Jan 10 2017, 10:59 PM

Utterly Eccentric and Moderator
Posts: 4,062
Joined: 4-March 00
From: Bristol / Ipswich / Spain

This DECOMPILE routine has saved the day for me several times! There are also some useful ideas in the thread.

Best of luck,


I would like to remind members and visitors that UtterAccess is a NON SMOKING website. In that respect, it is the worlds first Thank you for not smoking.
Go to the top of the page
post Jan 12 2017, 08:50 PM

Posts: 247
Joined: 15-December 16

Thanks for advice. it happens i make backups regularly and with different names. in this case the previous backup was two days old. it meant I had a lot of work to redo, but had to be done.

that for decompile page!

appreciate all comments!
Go to the top of the page

Custom Search
RSSSearch   Top   Lo-Fi    25th June 2018 - 06:25 AM