Fields Locked

RaptorZ

Registered User.
Local time
Today, 08:45
Joined
Feb 1, 2006
Messages
12
I do not get this, can anyone come up with an idea or area that I could look into. There were fields that the sales reps could write notes into, they are not able to type in these fields anymore. I had a back up copy of the DB prior to this event happeneing. I compared the field in design view and all the values are exactly the same. But the Prior version I can still type in, the newly updated version I can't.

I tried copying the field from the DB where it worked and pasting it where the one not working was, and that didn't work. So, I got to believe there is a GLOBAL lock somewhere available. Unfortnately, the books I have do not discuss this situation at all.

Does anyone have any ideas...I have to think this is an easy fix, but I can't figure it out.

Thanks!
 
Look at the "Locked" property for the fields (controls).
 
Yeah, They all say "no" to locked and they are all enabled. That's what's really confusing. The DB did crash, could it have corrupted those fields?

Thanks
 
llkhoutx said:
Possibly. Make a copy, then compact & repair.


So you're suggesting that I copy the Form from the DB that works, then paste it in giving it the same name, then immediately compact and repair DB?

Just want to make sure I have this right

Thanks for the help/ideas too. I am almost at my wits end with this.


One other thought I had was to take all the forms from the older version where the text fields work and copy them and paste them into the Current DB, however, it asks me what I want to name them, really I just want to overwrite and keep the same name. I am wondering if there is more than one form that I'd have to change.

I also read in a book that in older versions (mine is ver 9 access2k) that the tables can effect the status of the text boxes. Do I do the same (replace the table in the one that is working into the current DB)? I just need to keep the current DB information as there are notes that have to be retrieved for callback purposes.

Unfortunately I took over a DB that is not documented, and has horrendous Naming conventions for all the forms/Tables/Query's, and the 1 person who worked on this for years is now gone.
 
Unfortunately I took over a DB that is not documented, and has horrendous Naming conventions for all the forms/Tables/Query's, and the 1 person who worked on this for years is now gone.

The above is standard practice; even for fortune 100 companies. There no ROI on documentation.

Another idea is to create a new blank mdb, then import all mdb objects into the blank mbd via the File|Get External Data|Import menu; on the Import Object menu, click Options and check the Relationship and Menu and Toolbars checkboxes to import those too. I do this when my mdbs get corrupted.

A corrupted form and it VBA can look ok, but can be corrupted. If just one form is bad, change its name, create a new form and copy all the controls, section by section, and also all the VBA. This can be tedius with forms have multiple children. Children have to be done similarily.
 
Unfortunately I took over a DB that is not documented, and has horrendous Naming conventions for all the forms/Tables/Query's, and the 1 person who worked on this for years is now gone.

The above is standard practice; even for fortune 100 companies. There no ROI on documentation.

Another idea is to create a new blank mdb, then import all mdb objects into the blank mbd via the File|Get External Data|Import menu; on the Import Object menu, click Options and check the Relationship and Menu and Toolbars checkboxes to import those too. I do this when my mdbs get corrupted.

A corrupted form and it VBA can look ok, but can be corrupted. If just one form is bad, change its name, create a new form and copy all the controls, section by section, and also all the VBA. This can be tedius with forms have multiple children. Children have to be done similarily.
 
Unfortunately I took over a DB that is not documented, and has horrendous Naming conventions for all the forms/Tables/Query's, and the 1 person who worked on this for years is now gone.

The above is standard practice; even for fortune 100 companies. There no ROI on documentation.

Another idea is to create a new blank mdb, then import all mdb objects into the blank mbd via the File|Get External Data|Import menu; on the Import Object menu, click Options and check the Relationship and Menu and Toolbars checkboxes to import those too. I do this when my mdbs get corrupted.

A corrupted form and it VBA can look ok, but can be corrupted. If just one form is bad, change its name, create a new form and copy all the controls, section by section, and also all the VBA. This can be tedius with forms have multiple children. Children have to be done similarily.
 

Users who are viewing this thread

Back
Top Bottom