 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Forms Programming / August 2005STOPPING MS ACCESS 2000 AUTOMATICALLY SAVING FORMS
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? 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. > >Is there a setting somewhere (or code) that will stop this happening? > >Is Access saving the underlying table? If so, why? [quoted text clipped - 3 lines] > > John W. Vinson[MVP] >If this problem can be removed by setting a file attribute, >can it be done another way? 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] > 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 [quoted text clipped - 4 lines] > > or acSavePrompt. Or possibly the line DoCmd.Save which saves the design of the form, not the record data.  SignatureDirk Goldgar, MS Access MVP www.datagnostics.com (please reply to the newsgroup) 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. > > 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 [quoted text clipped - 10 lines] > > 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. [quoted text clipped - 11 lines] > record saving occurs (or not) depending on user choices made on those > forms i.e. in Case statements etc. 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. SignatureDirk Goldgar, MS Access MVP www.datagnostics.com (please reply to the newsgroup) 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. > > Searching the application for DoCmd.Save, acSaveYes and acSavePrompt > > yielded 1 DoCmd.Save, 2 acSaveYes and 0 acSavePrompt. [quoted text clipped - 21 lines] > disappears. That's the only other thing I can I can think of that would > be saving design info without being told to. > Hi. > [quoted text clipped - 10 lines] > > I must find out what itis purpose is. 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. SignatureDirk Goldgar, MS Access MVP www.datagnostics.com (please reply to the newsgroup) 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. > >If this problem can be removed by setting a file attribute, > >can it be done another way? [quoted text clipped - 18 lines] > > John W. Vinson[MVP] |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.