I'm using Access 2007. The file is in Access 2003 format.

When I try to make changes to a particular form, if I close without saving, it prompts me to save as usual. But the form won't close. When I close and opt to not save, changes aren't saved.

It doesn't matter if I do this at work or at home. Either way I know for a fact no one else is using the MDB, simply because I don't get an error saying so, and I'm doing this late enough I know everyone else is gone. And of course on my home PC, I'm the only one using it!

If I manually save and then close, I'm still prompted to save the form, and the same thing happens:

1) Form won't close
2) When I close, I'm prompted to save
3) When saving, the form won't close
4) The only way to close is to NOT save the changes

There are quite literally NO errors at all. I've done quite a bit of googling in the past 2 hours and only found this one bit that may help:

"There's a max of 7xx (seven hundred something) controls you can add, and removing a control doesn't decrease the talley." I'm guessing this form may be at it's supposed design limit or something. It has been through EXTENSIVE design and re-design. I suppose I should also mention that this form is very complex. But it works fine. All references are found, etc. Just won't save any more changes. Seems like a re-design is due...

Please help!

I've had this happen before, but I can't remember how I did it. I think it was the result of random tinkering.

In the meantime I'm gonna tinker, and hope I don't mess anything up worse. (Usually I don't, I'll just spin my wheels and burn out, or get lucky.)

PS. Thanks for all the help in the past. My database has helped with work load a TON, and it's all thanks to the help I got here.

on a COPY of your database:

ctrl-G (opens the immediate window) and type:
SaveAsText acForm, "YourFormName", "C:\Temp\YourFormName.txt"
and hit enter.

With luck you will create the form-as-text.
If you are unlucky, this step will fail with an error - see LastGasp below.

Delete the form from the COPY of your application.

Compact the COPY of your application

Open the COPY of your application and Ctrl-G again and type:

LoadFromText acForm, "YourFormName", "C:\Temp\YourFormName.txt"


a shorter way to do this is to \Decompile a COPY of your application.
this (undocumented) switch seems to work by moving all MDB objects --> text --> new MDB.
do some googling for "decompile" - there are some wrinkles to the process.
Decompile or how to reduce MDB/MDE size and increase startup performance is a good place to start.

when i was coding a lot in A03 i did a daily MDB --> text --> New MDB, and kept the .txt files as my backup (only 20% of the size of the .MDB) i used a home-made utility ...maybe you can experiment importing the attached two objects-as-text into a new .MDB and see if it will work for you - the objects (a form and a module) were part of my utility exported as text using the utility itself. if i recall correctly these forms require a DAO reference set. sorry i don't have access on this machine to see if the .txt are viable.

...i don't know if any of these tricks have a chance of working for A03 forms in A07. worst case you might need to dig up an old A03 installation.

only try this stuff on a **COPY** of your .MDB

izy

LastGasp.

if you can't export to text or \Decompile then it looks like even the underlying canonical text is corrupt (...which is unusual!). one possibility (again on a COPY of your MDB):
make sure Auto NameCorrect is *OFF* (and it always should be!!!)
copy all the code from the offending form's module to Notepad.
delete all the code in the offending form's module.
compact the MDB.
rename the form
make a new form with the original name of the offending form
copy/paste all controls from old to new form
...and now try rebuilding your events & code using the stuff you have in notepad (create events normally but use the event handler code content from Notepad to save retyping).

now export to text or \Decompile

izy

FORGOT TO MENTION: if this is not a split FE/BE (i.e. you have data tables in the MDB), get the data into a data-only MDB ("BE") before doing anything else.

Alright thanks izy!!

I'll try it and get back to ya :-)

Ok try not to laugh ...

I've never actually had all of my 50+ forms in the code window. When I used to use the Wizard to add a form, that seemed to be the only process that included a form in the code window. I moved to designing the forms manually for more flexibility.

Since I did that, forms I created stopped appearing in the code window. I've never directly edited code that applied to forms in the code window. Only once in a blue moon will I modify one of my 4 main modules (that were copy pasted from google and dbforums).

A while ago, a random error erased the entries of those few forms from the code window. It turned out to not affect how any of my forms worked, so I considered it a good thing at the time. It also solved a random need to re-compile that I could never get a bead on.

So... again, seemed to be a good thing, but now I'm wondering. I haven't seen any code related to a form in a long time. Is that bad? Is it even necessary for functionality? I'm under the impression that my form may be hosed, which wouldn't be the end of the world.

So where do i stand now? I'm going to go back to your posts and make sure I followed your steps carefully in the meantime.

Thanks for all your help btw.

=====

EDIT: One more symptom: the form can't be renamed. Again, no error. The new name appears for a split second, then it changes back to the old one.

hmmmm

i'm a bit puzzled about your reference to forms in the code window.
forms exist as objects.
forms optionally have code modules associated with them.
forms don't show in the code window (tho perhaps their associated code modules do).
maybe it's a terminology thing.

you have 50+ forms
one of the 50+ is being troublesome.
whether or not you have intentionally added a code module to the troublesome form and typed some stuff in that module, the form itself is defined in code (written for you in the background by big-A ...see FRM--frmExport.txt above - open in notepad - 99% of the stuff you see is directly from big-A without me typing = the form definition). similar stuff exists for all forms (with or without a "code module")

if your troublesome form won't save control edits, the form definition stuff is in trouble.
save-as-text the form definition*
delete the form
import-from-text the form definition*

* the form definition will include all of big-A's auto-stuff needed to stick the form on the screen, plus any code you have optionally added to the form's module to handle events etc etc.

I haven't seen any code related to a form in a long time
the form definition stuff generated by big-A doesn't show (...except when you export to text and look at the .txt file)

Is that bad? Is it even necessary for functionality?
depends on who you are. for me, a form exists ONLY to exploit the functionality of my code (keep in mind i never used macros). if you can make a form do useful stuff for you without code in it's module then it's fine for you.

but you still have an issue with big-A's auto-generated form-definition code on the troublesome form. take it to text and back and you should be ok.

izy

now i see your EDIT: can't rename is not nice.

can you SaveAsText / LoadFromText ?

izy

You mean through the immeadate window? Or by right clicking on it? In the immeadate window there are now forms for me to select from.

All I can see so far is > right click > export > text file ...

but i'm sure that's not what you are talking about.

======

EDIT: Immeadate window = CTRL + G right? Or ALT + F11? It looks the same either way, only 4 modules, and no forms.
EDIT2: Ok, sorry, I'm tracking now. Trying "SaveAsText" in the immeadate window on another form ... and the problem form.

Ok I finally see what you meant by SaveAsText.

It works fine for all other forms but the problem form, which is also my oldest form... not entirely surprising. Trying your other steps again...

=====

EDIT: Your other steps (copying the code) ... well ... there is no code to copy ... so ... abort mission?
EDIT2: Ok right, copy all the controls. Trying that.

Holy moly. Finally got it! Not a perfect copy, but at least 99% of my work is preserved.

Thanks izy!

So is it a pretty good practice to save those forms in that text format as backups?

99% recovery is not a bad result from a corrupt form.

i don't know about "good practice".
my practice was regular /decompile (later replaced by MDB >> txt >> MDB) during front end development. once i had the .txt files i kept them as backup in addition to keeping copies of significant "milestone" MDBs.

izy