Crash When Add Option Group

fenhow

Registered User.
Local time
Today, 08:18
Joined
Jul 21, 2004
Messages
599
Hi,

I am working on a form, everytime I add an Option Group with the value to store the selection to a table and save the form Access Crashes.

If I create a new form I can create the option group no problem and save it.

Can someone tell me why this might be happening?

Thanks.

Fen How
 
Sounds like corruption. Import all of your objects into a new db and then do a Compact and Repair. See if that helps.
 
Similar issue with 2k3 ... started new db, relinked back end tables, copied queries and forms, then attempt to add an Option Group to an existing form ... as soon as I save the Form, Access Crashes ... the original file saved the form change BUT the form NO longer opens in RUN or DEV modes even after a compact/repair ... did a REPAIR on the 2k3 installation ... in the original file, attempted to do a Documenter on the Form but it is providing an error: application-defined or object-defined error ... this particular mdb file must be retained for existing installations/licenses ... moved new mbd to another machine loaded with 2k3 ... the Wizard Addin installed ... added the option group ... attempted to save form and ACCESS won't get past the Save Objects Dialog ... but it does gracefully allow a cancel ... is there some kind of log file that might reveal what the issue is or any other ideas?


Hmm ... found the Access Crash report ... nothing revealing ... went back to alternate machine and found if the form is saved a second time it allows saving the object .... HOWEVER ... closing the mdb doesn't retain the Option Group ... also copying the file back to the original machine doesn't retain the Option Group
 
Last edited:
Hmm, sounds like you need to create the Form from scratch providing it is really only that Form that won't take the Option Group addition.
 
I would decompile the db, compact and repair. If that does not work you can save the form as text and load from text.
http://www.allenbrowne.com/ser-47.html
Code:
This is an undocumented technique that may rescue a bad form or report by exporting it to a text file, and instructing Access to recreate it from the text file.
Make a backup of your database.
Open the code window (Ctrl+G) and look through the modules (Windows menu.)
If you can see a module for this form/report, copy the text out to Notepad, and save it.
Open the Immediate Window (Ctrl+G), and export the form/report as a text file. Enter something like this:
    SaveAsText acForm, "Form1", "C:\MyFolder\Form1.txt"
substituting your form name for Form1 and your directory for MyFolder.  Use acReport if the problem object is a report.
Verify that the text file was created in the folder you specified.
Delete the form from the database.
Select it in the Navigation Pane (Access 2007 or later) or Database Window (previous versions), and press Del.
Compact the database: 
In Access 2010, Compact and Repair Database on the Database Tools ribbon.
In Access 2007, click Office Button (top left) | Manage | Compact.
In Access 95 - 2003, Tools | Database Utilities | Compact.
Open the Immediate Window (Ctrl+G). Enter something like this:
    LoadFromText acForm, "Form1", "C:\MyFolder\Form1.txt"
substituting the same things you did at Step 3 above.
You will receive an error message at Step 3 if Access cannot make sense of the form to export it. You will have to delete the form and re-create it, but if you saved the code at Step 2 you can at least paste that back into the new form's module after you create it.
If Step 3 works without error, there is a good chance the rest of the steps will succeed too.
 
Ok thanks for the idea ... so ... created a NEW Form with just the Group Option ... this saved with no issues ... THEN ... copied this object back to the Form and it now saves ... guess this is a workaround ... BUT ... WT_ ? :banghead:


The reply for save form to text file must have been sent while I was replying to the new form idea ... I have now pulled up the original mdb file where the form won't open and tried the save option from the immediate window ... ACCESS IMMEDIATELY CRASHES ... so ... appears I have completely lost all the updates made to this form due most likely to this annoying quirk ... save often didn't help ... need a continuous backup save to maintain copies of all changes as they are made/saved ... undo wasn't available after crash recovery ... 20+ years back, I was using check in/out applications that might have mitigated an issue like this ... anyway thanks for the link.
 
Last edited:
Well, I would not be copying anything back to the original Form but recreating it and deleting the old corrupt one. And yes, I would make a back-up during development just in case.

Side note, the reason I suggest a brand new Form is because Forms have *lifetime( control limit which does not get reset when you remove a control, it just keeps counting. I do not remember what that limit is but that could be the cause of why adding a control to your existing Form causes crashing. While you are getting away with a work around this may only be temporary.
 
Side note, the reason I suggest a brand new Form is because Forms have *lifetime( control limit which does not get reset when you remove a control, it just keeps counting. I do not remember what that limit is but that could be the cause of why adding a control to your existing Form causes crashing.
That is why I recommend save to text and load from text. Solves that issue, while at the same time can save hours of work rebuilding from scratch.
 
@MajP, you are correct will accomplish the same thing.
 
Side note, the reason I suggest a brand new Form is because Forms have *lifetime( control limit which does not get reset when you remove a control, it just keeps counting. I do not remember what that limit is but that could be the cause of why adding a control to your existing Form causes crashing. While you are getting away with a work around this may only be temporary.

Hi Gina
The limit is 754. See Access specifications

Whether you copy all controls & code into a new form or use save as text/load from text, the outcome is the same. You are starting the count again from zero.
 
max 754 Control Changes to a form/report ... one might expect this was meant to allow for UNDO ... but ... UNDO didn't work in this situation and with a handful of mostly static controls (< 30), defined at most once over a 2 year period of service, kind of hard to fathom hitting 754 changes. ... The form now being used isn't the original form ... there are sizing and positioning of objects consistent across 9 tab subforms that I didn't want to waste time reinventing so I just copied one of the minor tab subforms and made the appropriate link changes along with doing a dump and reload of Form Event Code ... as noted above this may be easier and better to do with a TEXT dump and reload of the Form ... now that I have a working backed up form, I will attempt another Text Dump and Reload before adding back all the lost changes from yesterday


Thanks everyone for your help muchly appreciated
 

Users who are viewing this thread

Back
Top Bottom