It was working so well, until... (1 Viewer)

martinez71

New member
Local time
Today, 23:13
Joined
Mar 8, 2022
Messages
3
Hello, I'm new here, and I'm here because I've been stupid with my lovely database, which as a freelancer I've been using problem-free since 2008 (when a friend helped me to set it up), to enter and keep track of assignments from my clients.

The other day I realised there were a couple of fields that I never used, so I went into Design View and deleted them. Decluttering. Great idea. Without making a backup copy. GREAT IDEA. Because, well, because stupid.

So now an apparently unrelated field is playing up, and because I haven't tinkered with the nuts and bolts of it since 2008, which is about three hundred years ago, I can't remember how to fix anything, or even if I ever knew how to in the first place.

So, that's why I'm here. And I'll be asking for your help very shortly :)

Cheers!
Mart
 

Jon

Access World Site Owner
Staff member
Local time
Today, 23:13
Joined
Sep 28, 1999
Messages
5,903
Welcome to the forums! We are the most active Microsoft Access community on the internet by far, with posts going back over 20 years!

To get started, I highly recommend you read the post below. It contains important information for all new users to this forum.

https://www.access-programmers.co.uk/forums/threads/new-member-read-me-first.223250/

We look forward to having you around here, learning stuff and having fun!
 

Mike Krailo

Active member
Local time
Today, 18:13
Joined
Mar 28, 2020
Messages
609
Why not simply add the deleted fields back in?
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 18:13
Joined
May 21, 2018
Messages
6,353
The fix is probably just some additional cleanup. However, knowing where to look might be hard for you, but easy for us. If you can zip and attach a database that would help. If there is proprietary data then you can possibly scramble the data (which we can describe) or provide just the problem areas in a stripped down database.

If you removed fields from tables then problems could be in these most likely areas
1) Queries may use those field names you need to remove the reference from any queries, rowsource, recordsource
2) Forms controls could be bound to those fields. Need to remove those controls also
3) Code could reference those fields (I am guessing not the case you would have code for fields not used)
 

AngelSpeaks

Active member
Local time
Today, 17:13
Joined
Oct 21, 2021
Messages
238
Do you by any chance use a cloud based backup service? Just the other day, I restored by database from the cloud backup.
 

martinez71

New member
Local time
Today, 23:13
Joined
Mar 8, 2022
Messages
3
Why not simply add the deleted fields back in?
For one very simple reason... it genuinely hadn't occurred to me. Thanks for the suggestion!

I will attempt it now. When I inevitably fail to work out how to do it, should I ask questions here or start a new topic in the Discussion area?

I don't use a cloud-based backup service, no. That's far too sensible an idea!

Thanks all.

Edit: running Access 2013, Windows 10.
 

GPGeorge

Grover Park George
Local time
Today, 15:13
Joined
Nov 25, 2004
Messages
662
Would it improve your day to reveal that you are not the first person to stumble down this path?
And that two of the lessons frequently learned include:
  1. You can't have too many backups
  2. Don't delete things you think you don't need. Rename them instead and see what breaks.
I do things like renaming fields from, say "CompanyMascot" to "Z_CompanyMascot" instead of deleting the field. That way, recovery is as simple as restoring the original name.
 

martinez71

New member
Local time
Today, 23:13
Joined
Mar 8, 2022
Messages
3
Would it improve your day to reveal that you are not the first person to stumble down this path?
And that two of the lessons frequently learned include:
  1. You can't have too many backups
  2. Don't delete things you think you don't need. Rename them instead and see what breaks.
I do things like renaming fields from, say "CompanyMascot" to "Z_CompanyMascot" instead of deleting the field. That way, recovery is as simple as restoring the original name.
I'm normally quite good at NOT doing things like the thing I've done, or trying it out first with a backup.
But sometimes I could use a backup brain, for when my main brain fails me.

Anyway, I have a hot update for you all. I made a copy of the file, to try to fix things, and the problem went away. But only in the copied file. The original file still had the problem.

So I closed it down again. Contemplated life for a short while. Opened the original file again. And the problem had now disappeared there as well.

So... er... there's a lesson for us all there. Possibly. If we look for one.

Thanks for all your help, interest, time taken, etc. Much appreciated!
 

theDBguy

I’m here to help
Staff member
Local time
Today, 15:13
Joined
Oct 29, 2018
Messages
18,962
Hi. Lots of good advice already, so just:

Welcome to AWF!
 

Gasman

Enthusiastic Amateur
Local time
Today, 23:13
Joined
Sep 21, 2011
Messages
10,531
Are you sure Windows has not created a version?
I recovered a file just a while back using that feature.

1646763431535.png
 
Last edited:

isladogs

CID VIP
Local time
Today, 23:13
Joined
Jan 14, 2017
Messages
16,214
Similar to George's comments in post #7, I test for redundant objects/fields by prefixing with zz then waiting a month or so to check whether anything breaks
Just to add to that advice, before renaming any objects or fields make sure you switch off Name Autocorrect.
Some developers advise switching it off permanently but I find it very useful if used with care.
 

GPGeorge

Grover Park George
Local time
Today, 15:13
Joined
Nov 25, 2004
Messages
662
Similar to George's comments in post #7, I test for redundant objects/fields by prefixing with zz then waiting a month or so to check whether anything breaks
Just to add to that advice, before renaming any objects or fields make sure you switch off Name Autocorrect.
Some developers advise switching it off permanently but I find it very useful if used with care.
I've gone back and forth on that practice. Early on many claimed that Autocorrect was the equivalent of Autocorrupt and simply flat out recommended avoiding it. I was at a conference on the MS campus a decade or so ago and one of the Access dev team members assured us that they'd done a lot of work to make it more reliable. I think that's accurate, based on more recent experience. However, once I get an application to what I think will be the final data model, I do turn it off on the assumption that it's overhead I don't need on a stable design.
 

isladogs

CID VIP
Local time
Today, 23:13
Joined
Jan 14, 2017
Messages
16,214
I've gone back and forth on that practice. Early on many claimed that Autocorrect was the equivalent of Autocorrupt and simply flat out recommended avoiding it. I was at a conference on the MS campus a decade or so ago and one of the Access dev team members assured us that they'd done a lot of work to make it more reliable. I think that's accurate, based on more recent experience. However, once I get an application to what I think will be the final data model, I do turn it off on the assumption that it's overhead I don't need on a stable design.
My feelings exactly.
Almost 20 years ago, both memo fields and name autocorrect were definitely responsible for corruption on many occasions.
Like many others, I avoided their use at the time. However, in the last 10 years or more, I no longer find either of those a cause for concern and indeed use both features regularly in my own databases. Of course, as George stated, once at the deployment stage, there should be no further need for using name autocorrect
 

Users who are viewing this thread

Top Bottom