STOPPING MS ACCESS 2000 AUTOMATICALLY SAVING FORMS

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi all.

I have an A2K app. with a central menu system, from which the user clicks on
the menu option and a form opens as a result (normally as a popup, non-modal
and, therefore, over the top of the main menu).
The menu(s) form uses a table as a data source, which holds the menu text
and other datum, which are used as parameters for Subs in a general
"security" module.
When a user clicks a menu option, the appropriate security Sub is called and
a comparison made to the relevant permission in the "users" table. The
resultant form is then opened, or the user is told they do not have
permission to do so.

If successful, the time taken to open the form (after menu choice) is
siginificantly increased because Access is automatically saving the main menu
(I think). Anyhow, the office assistant indicates a "save" action before
opening the chosen form.

Having looked at the form properties and code modules, I cannot find any
reason why Access is saving anything when the user chooses a menu option.
(No changes are being made to either form design, code or table).

Is there a setting somewhere (or code) that will stop this happening?
Is Access saving the underlying table? If so, why?

Any advice will be welcomed.
 
Is there a setting somewhere (or code) that will stop this happening?
Is Access saving the underlying table? If so, why?
Click to expand...

Please post the code. It shouldn't be saving anything unless your code
is erroneously doing so.

John W. Vinson[MVP]
 
Hi John,

Thanks for coming back to me.

It comes to pass that making the .mdb file read-only stops this apparent
saving.
Data can still be entered and retrieved etc. It appears that only the object
defs cannot be changed.
(Access throws up an annoying message about the ro attribute on startup,
which would be nice to suppress if it could be done).

I am puzzled. If this problem can be removed by setting a file attribute,
can it be done another way? (Thus getting rid of the ro message on startup)

Regards.
 
If this problem can be removed by setting a file attribute,
can it be done another way?
Click to expand...

Yes, I'm sure it can, since I have NEVER ONCE seen this behavior in
any Access database.

Access *does not save design changes to forms* unless you ask it to do
so.

You have something in the code (which you have not posted, so I can't
tell what it is) which is causing this problem. It's not Access that's
causing the problem; it's *YOUR CODE*. My guess is that you have
something like

DoCmd.Close acForm, strFormName, acSaveYes

or acSavePrompt.

Fix your code, by changing to acSaveNo in my example, and the problem
will go away.

John W. Vinson[MVP]
 
John Vinson said:
You have something in the code (which you have not posted, so I can't
tell what it is) which is causing this problem. It's not Access that's
causing the problem; it's *YOUR CODE*. My guess is that you have
something like

DoCmd.Close acForm, strFormName, acSaveYes

or acSavePrompt.
Click to expand...

Or possibly the line

DoCmd.Save

which saves the design of the form, not the record data.
 
Searching the application for DoCmd.Save, acSaveYes and acSavePrompt yielded
1 DoCmd.Save, 2 acSaveYes and 0 acSavePrompt.

The DoCmd.Save and acSaveYes occurances appear in parts of the app. which
would be rarely used, and are far removed from the main menu where the
problem is taking place.
(Also, they should only be executed depending on user choice).

I do have :

DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70

in the code of a few forms opened directly from the menus, though the record
saving occurs (or not) depending on user choices made on those forms i.e. in
Case statements etc.
 
Faberman said:
Searching the application for DoCmd.Save, acSaveYes and acSavePrompt
yielded 1 DoCmd.Save, 2 acSaveYes and 0 acSavePrompt.

The DoCmd.Save and acSaveYes occurances appear in parts of the app.
which would be rarely used, and are far removed from the main menu
where the problem is taking place.
(Also, they should only be executed depending on user choice).

I do have :

DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70

in the code of a few forms opened directly from the menus, though the
record saving occurs (or not) depending on user choices made on those
forms i.e. in Case statements etc.
Click to expand...

This is a bit odd, as it doesn't *sound* like you hve code that is
saving the form. First, what exactly makes you think the form is being
saved? What do you observe?

Something you might try, just as a long shot, is this: Click Tools ->
Options..., go to the General tab, and see if "Track name AutoCorrect
info" is checked. If it is, uncheck it and see if the problem
disappears. That's the only other thing I can I can think of that would
be saving design info without being told to.
 
Hi.

What I observe is :

The office assistant (cat) opening a file drawer, and placing a file in the
draw - the draw then closes. Just like any save action.

I've just tried your suggestion of unchecking "Trackname autocorrect info".
It seems to have done the trick!! ?? (I will do more testing, but it looks
like it's worked)

The obvious next question is : why?

I must find out what itis purpose is.

Thank you.Thank you.Thank you.
 
I'm letting you know :

I have since received a constructive post, suggesting that I uncheck the
"Track Name Autocorrect Info" setting on the "General" tab in Options.

Having done so, the problem I began this thread about disappeared.

I can, therefore, only assume that it was not *MY CODE* and that "Access
*does not save design changes to forms* unless you ask it to do" is not
altogether accurate.

"By default, Access 2000 and higher maintain a list of changes to database
objects and will automatically change references to those objects on forms
and reports."
(taken from http://msaccessadvisor.com/doc/15022)

I am (again) assuming that Access will save the list AUTOMATICALLY as part
of the process, especially as it was doing so whether changes to design or
object references were made or not.
Of course, I could be wrong.

Anyway, the problem appears to have been solved.
 
Faberman said:
Hi.

What I observe is :

The office assistant (cat) opening a file drawer, and placing a file
in the draw - the draw then closes. Just like any save action.

I've just tried your suggestion of unchecking "Trackname autocorrect
info". It seems to have done the trick!! ?? (I will do more testing,
but it looks like it's worked)

The obvious next question is : why?

I must find out what itis purpose is.
Click to expand...

The Name AutoCorrect feature works by recording the names and
dependencies of all the objects in the database, so that if you change
the name of an object, that change will magically be reflected
everywhere that name is used. Unfortunately, this means recording a lot
of information whenever design changes are made, and reading and
processing that information when objects are opened. I don't know
exactly how it works, but I do know that the process is very buggy and
causes lots of problems, so I keep it turned off as a rule. I suppose
it might be valuable in early stages of development, when object names
are more likely to be in flux, but I've never tried to use it.

In your case, it seems that Access believes there's some name
autocorrect information to record or retrieve whenever you open your
form. I'm not sure why. And because you have the Office Assistant
active, it shows that happening. I never knew the Office Assistant
would do that, because I keep it turned off.

Incidentally, John Vinson was right when he said Access wasn't saving
design changes to your form without being asked. This name autocorrect
information is different from what he or I would think of as design
changes. But I can understand the confusion.
 
Back
Top