Prompted to save form changes, but none made

[KellyJ]

One form in an Access 2000 format database has begun to show unexplained behaviour, whether opened in Access 2000 or 2003.

When I open the form (only Form view allowed), then switch to Design view, and then immediately close the form without making any changes, Access prompts:

“Do you want to save changes to the design of form …?”

Only one form in the database displays this behaviour, and consistently every time I do the above. In an earlier backup, closing the form in Design view proceeded normally without the prompt. The database is still in development, but I don’t recall what specific design change may have produced this effect.

(Typically, you receive such a prompt after viewing a form in Datasheet view, if for example you change a column width, but I’m not using Datasheet view with this form.)

The problem does not apparently affect the database user, and there is no data loss or corruption, but it is an inconvenience and irritant for me!

This is what I’ve done to investigate the problem, following many of Allen Browne’s tips at allenbrowne.com:

Back End

Although I didn’t suspect it, I imported it into a new database.

Front End

With a copy of the database:

1. Used Compact and Repair on a copy of the database.

2. Used command line to decompile the project code, then re-compiled.

3. Used command line to SaveAsText the offending form, then deleted the form in Database window, then used LoadFromText to re-create the form.

None of the above steps resolved the problem.

Any suggestions for what I might try next, or does anyone have a possible explanation for this behaviour?

James

 

[DCrake]

Create a blank database and import the offending form into it and try to replicate the issue. Can you do this?

 

[KellyJ]

David,

Thanks for the suggestion. I imported the offending form into a new database and linked to the relevant back-end tables. The problem is still there.

One other observation. If I open the form in Design mode initially, it closes ok without prompting. I only get the prompt to save changes if I open the form initially in Form view, then switch to Design view, and then immediately close the form.

James

 

[DCrake]

Then this implies that that it is assuming that the underlying data is dirty not that the form has changed in any way. If you do any development you should not be looking at the live data anyway. You should always point to a local copy of the tables for dev work. Then once complete revert the links.

 

[KellyJ]

I may have given the impression that there is a live user connected to the database back end, when I said "The problem does not apparently affect the database user". What I mean is that when using the database as a user would (i.e. no access to Design mode) it does not exhibit the problem, so it only affects me. During development, the database (FE and BE) are local to my computer.

> this implies that that it is assuming that the underlying data is dirty not that the form has changed in any way

The BE I'm using is one I created during my original testing, a new database with the original tables and data imported.

Is 'dirty' a status that is maintained by the BE database file, and if so can be carried over when importing the tables into a new db? If so, is there some way of clearing that 'dirty' status? There is no existing LDB file present before I open the form.

 

[dfenton]

Then this implies that that it is assuming that the underlying data is dirty not that the form has changed in any way.

This is wrong. Dirty records never generate a prompt by default (only if you've programmed one). This prompt only occurs with a design change to the form.

If there is any code that alters the form in design mode, or modifies sort order or the form's filter, then perhaps that's causing the prompt (though the latter two should not).

Try saving the form under a new name, then using Application.SaveAsText to save both copies out to a file so you can compare and see what is different between them.

 

[KellyJ]

David (Fenton),

Thanks for your suggestion, and this is the result.

I called the problem form "frmName" below:

Open database with only switchboard opened
Open Immediate window (Ctrl+G)
Save form frmName as text to c:\frmName.txt
Open frmName in Form view, then switch to Design view
Save form as frmName_New (in database window)
Save form as text to c:\frmName_New.txt

Used WinMerge to compare both text files:

Just below Begin Form,
... the original file has:

Checksum =764337456
Begin Form
AutoResize = NotDefault
AutoCenter = NotDefault
AllowAdditions = NotDefault
FilterOn = NotDefault

... the new file has:

Checksum =1588428038 DIFFERENT
Begin Form
AutoResize = NotDefault
AutoCenter = NotDefault
AllowAdditions = NotDefault
OrderByOn = NotDefault DIFFERENT PROPERTY

Further down, both Top and Bottom properties are different,

Then, for every instance of (for example)

GUID = Begin
0xf048cd11edecd043b4057430c0e12713
End

... each control's Guid value (about 40) is different in the new file

The CodeBehindForm section is the same for both files (no VBA code differences), which may explain why my earlier decompile/recompile didn’t help.

Apart from all the Guids being different, the FilterOn = NotDefault Vs OrderByOn = NotDefault looks unusual.

Does this help identify the problem David?

 

[KellyJ]

Following my last post, and for comparison, I repeated this test with another form, which is similar in complexity, but does not exibit the "save changes?" prompt problem.

This time, all the Guids were again different, so that may be normal every time a file is saved.

The form's Left, Top, Right and Bottom property values were different.

But, perhaps most significantly, both files had the same OrderByOn = NotDefault property this time (and the property FilterOn didn't appear in either file this time).

I just checked now, and this second (good) form in Design mode has Allow Design Changes = All Views (AllowDesignChanges = NotDefault in text file), whereas the problem form has Allow Design Changes = Design View Only (no AllowDesignChanges in text file). I had high hopes, so I tried changing this property in the problem form to All Views, but that doesn't solve the problem!

Maybe this leaves OrderByOn = NotDefault Vs FilterOn = NotDefault in the two text file versions of the problem file as a possible explanation - but how or why?

 

[dfenton]

The least complicated explanation of this is:

1. OrderByOn and FilterOn are being set in code at runtime, or by the user.

2. you have a CLOSE command button that is set to prompt for changes, i.e.,:

DoCmd.Close acForm, Me.Name, acSavePrompt

If you're using that code, you should change acSavePrompt to acSaveNo, which explicitly discards any runtime changes to the properties that get saved with the form.

The Allow Design Changes property controls only when the properties sheet displays. Stupidly, when MS implemented the ability to have the property sheet stay open when in view mode, they set this property to ALL VIEWS, which nobody wants, in my opinion -- the default clearly should have been DESIGN VIEW ONLY, but as with so many choices of defaults in MS products, they chose they intrusive default, i.e., the one that makes you have to deal with the results so that you notice the new feature.

The GUIDs are different because it's a different form, and that's to be expected.

The key thing here is the OrderByOn and FilterOn properties. Those are getting changed somewhere during the form's lifetime, either in code or interactively. The default for Access is that those properties get saved by default (without prompting), so I'm not sure why you're getting a prompt -- that's why I suggested you might have a custom CLOSE button with the wrong setting for the SAVE parameter.

 

[KellyJ]

David,

I believe you have solved this puzzle.

The code behind a Close command button on the form does include DoCmd.Close, but without any option specified, so acSavePrompt is the default.

> If you're using that code, you should change acSavePrompt to acSaveNo, which explicitly discards any runtime changes to the properties that get saved with the form.

That is useful advice, as there are indeed run-time property changes made in the Form_Open event, e.g. FilterOn is set False, OrderBy is set to a field name, and OrderByOn is set True.

Now, consider the following situations where the form is closed.

1. When the form is opened in Form view, close the form via the Close command button, executing the DoCmd.Close in the code behind. While there are some run-time property changes in Form_Open, and acSavePrompt is the default option, the form closes without any prompt! I’m not too concerned about it, but this doesn’t appear to be correct – it should prompt, which is why you advised acSaveNo.

2. While the form is in Design view, close the form via the Close button to the right of the Min Max button. There are no manual design changes (I made none), but there are the run-time property changes made by code when the form was first opened in Form view. So, Access issues a prompt to save.

> The default for Access is that those properties get saved by default (without prompting)
Is this documented?

I was able to confirm that the behaviour in #2 above is due to the run-time property changes. I did this by temporally commenting out the code which makes the property changes, and then found that closing the form in Design view no longer resulted in a prompt. (I may be able to include those property values permanently in the design, rather than in Form_Open.)

So, thank you David for your clear analysis and advice. I also learned to use SaveAsText to compare two versions of an Access form, which will no doubt be useful in other situations.

James