Property not found (1 Viewer)

Jgr4ng3

Registered User.
Local time
Today, 21:45
Joined
Jan 19, 2013
Messages
62
Hello

I have an access dB that stores meeting minutes as attached documents. This has caused the databas (I think this is why at least) to reach the 2gb limit.

Ive moves 50% of the records to a backup dB to hopefully reduce the size. I’ve then tried decompiling and compacting however it makes zero difference, I think because a message comes up stating ‘property not found’ During the process. This error appears to relate to a specific table, and it’s an old table which is no longer used, so I tried simply deleting the table with no luck - I just receive the property not found error. I cannot open the table in anyway either.

Is there anyway I can either resolve this error to enable compacting, or does anyone else have any other ideas at all please?

The dB is already split between FE/BE too.

Thanks in advance!
 

JHB

Have been here a while
Local time
Today, 22:45
Joined
Jun 17, 2012
Messages
7,732
Does it say which property that is not found?

Create a new database and import all (tables) into it.
If that not succeed, create a new one again and import 1 or 2 tables at a time, until you get the one that make your trouble.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 14:45
Joined
Oct 29, 2018
Messages
21,358
Hi. I agree with JHB. It might be safer to export the objects you need out to a new Access database. Good luck!
 

Jgr4ng3

Registered User.
Local time
Today, 21:45
Joined
Jan 19, 2013
Messages
62
Good idea, not sure why I didn't think of that. I know the offending table so I can export every table bar that one, hopefully then compact the new table if necessary, and use that. I assume I'll then need to re-link all of the tables from the FE to the new BE...
 

theDBguy

I’m here to help
Staff member
Local time
Today, 14:45
Joined
Oct 29, 2018
Messages
21,358
Good idea, not sure why I didn't think of that. I know the offending table so I can export every table bar that one, hopefully then compact the new table if necessary, and use that. I assume I'll then need to re-link all of the tables from the FE to the new BE...
Hi. You shouldn't have to relink the FE if you simply rename the old BE file and keep the new BE in the same folder and give it the old BE name. Cheers!
 

Jgr4ng3

Registered User.
Local time
Today, 21:45
Joined
Jan 19, 2013
Messages
62
Gone from 2gb down to 0.8gb! I think the old BE is just corrupt and couldn't compact because of that one corrupt table. Thanks all. Repointing the FE now so hopefully no problems..
 

Jgr4ng3

Registered User.
Local time
Today, 21:45
Joined
Jan 19, 2013
Messages
62
Hi. You shouldn't have to relink the FE if you simply rename the old BE file and keep the new BE in the same folder and give it the old BE name. Cheers!

Great idea!!
 

theDBguy

I’m here to help
Staff member
Local time
Today, 14:45
Joined
Oct 29, 2018
Messages
21,358
Gone from 2gb down to 0.8gb! I think the old BE is just corrupt and couldn't compact because of that one corrupt table. Thanks all. Repointing the FE now so hopefully no problems..
Hi. Glad to hear you got it sorted out. Good luck with your project.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:45
Joined
Feb 28, 2001
Messages
27,001
If I may suggest a palliative preventative measure? Don't store the documents in the database. Store them in the same folder as the BE file and just include a link to that file that shows the name and path. Rarely requires more than 100 bytes to do that. If you have the fully qualified path name, you are golden because you can open it any time you need to with that information. Might take a little work, but it SHOULD reduce you from 0.8 GB for the BE to a LOT less, maybe even a couple of decimal places less depending on the size of those documents. Then, when backing things up or doing a Compact & Repair, your smaller DB size means faster operation - which turns into "less likely to hiccup because of the smaller window of opportunity."

Just an idea for you to consider.
 

Jgr4ng3

Registered User.
Local time
Today, 21:45
Joined
Jan 19, 2013
Messages
62
If I may suggest a palliative preventative measure? Don't store the documents in the database. Store them in the same folder as the BE file and just include a link to that file that shows the name and path. Rarely requires more than 100 bytes to do that. If you have the fully qualified path name, you are golden because you can open it any time you need to with that information. Might take a little work, but it SHOULD reduce you from 0.8 GB for the BE to a LOT less, maybe even a couple of decimal places less depending on the size of those documents. Then, when backing things up or doing a Compact & Repair, your smaller DB size means faster operation - which turns into "less likely to hiccup because of the smaller window of opportunity."

Just an idea for you to consider.

No, you're definitely right. If I was to start over I'd certainly be designing it that way - unfortunately I started building this system which I was 17 and rather inexperienced - there is so much I would fix, but we're slowly retiring different modules within it into other hosted solutions, so eventually it won't exist - pretty sad times for me really!! But because of this, there isn't much use for me investing much in it as the meeting document management is getting replaced within the next three months
 

Micron

AWF VIP
Local time
Today, 17:45
Joined
Oct 20, 2018
Messages
3,476
Gone from 2gb down to 0.8gb! I think the old BE is just corrupt and couldn't compact because of that one corrupt table. Thanks all. Repointing the FE now so hopefully no problems..
I think not. Since I never use the attachment field, I can only provide anecdotal evidence, which is this:
Others who do store attachments have "removed" them but still couldn't get the file size down enough to attach to a post. I consented to download their file (something I prefer not to do) and found that copies of the files are kept in a hidden system table and they are viewable. Importing everything into a new db would mean that the system table in the new db has no file copies, hence the db will likely be smaller but who knows for how long. When, how or why they end up there I don't know and don't really care because as I said, I never store attachments in a db. Thus I doubt it was corruption at all.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:45
Joined
Feb 28, 2001
Messages
27,001
slowly retiring different modules within it into other hosted solutions, so eventually it won't exist

I understand your sadness, but look at it this way. You got things to work well enough to go on from there. You made progress. You learned some things - including that some ways are better than others. And when you can retire this solution completely in favor of those other technologies, it did its job and you can let it retire satisfied that you did your best (at the time) and did whatever you did in a relatively economical manner.
 

Users who are viewing this thread

Top Bottom