Well it was a general question to everyone who posted. I still don't see a solution, and was wondering aloud if the workaround was what I had to live with. Sorry, but I disagree with you, Itsme; no one has presented "the answer" to me yet.
It is OK to disagree.
First of all, I do not have any models that I can easily trouble shoot the issue with. The way I see it is your problem is
acQuitSaveAll
This command is requesting to save design changes. It does not seem to be playing well with the autoexec macro you created when you updated your startup settings.
When you opened and losed the form with the line of code you added it relieved it seems to have relieved the autoexec macro's responsibility to the form.
I would suggest not using acQuitSaveAll
The other option would be to use it somewhere that did not conflict with an RT environment. Perhaps there is code you can add that is similar to opening and closing the form. Code that does not cause flashing on the screen but tells Access it is OK to SAVE the FORMS.
It is OK to disagree.
First of all, I do not have any models that I can easily trouble shoot the issue with. The way I see it is your problem is
acQuitSaveAll
This command is requesting to save design changes. It does not seem to be playing well with the autoexec macro you created when you updated your startup settings.
When you opened and losed the form with the line of code you added it relieved it seems to have relieved the autoexec macro's responsibility to the form.
I would suggest not using acQuitSaveAll
The other option would be to use it somewhere that did not conflict with an RT environment. Perhaps there is code you can add that is similar to opening and closing the form. Code that does not cause flashing on the screen but tells Access it is OK to SAVE the FORMS.
Sorry, this is a massive, inherited application. I cannot easily share it as it will likely generate more questions than answers and though I am just a disgusted with its design as many of you likely will be, I have to stay focused on this little hiccup.
Again, even assuming acQuitSaveAll makes a difference, it does not explain why the Exit button works fine if I start the application from Design mode.
DoCmd.Quit allows three options: acQuitPrompt, acQuitSaveAll and acQuitSaveNone. I didn't want to be prompted so I tried the last two options. It makes no difference. I didn't think it would hurt so I picked acQuitSaveAll. But regardless, it makes no difference.
I am not using an autoexec macro. When I start my app. It loads the form listed in Options-Current Database-Display Form: That form happens to be "Login Screen"
Again, why would it work fine starting in Design mode but not starting the app by double-clicking on the .accdb?
I would not try too many changes at any one time. You want to identify where the problem lies. I have a couple things you can try listed below. One at a time, you can see if there are any differences in RT. BTW, I am not currently looking at 2010 DoCmd's.
Rather than using acQuitSaveAll in the form with DoCmd.Close, you might try
acQuitPrompt
acQuitSaveAll is default and Docmd.Close is the same as DoCmd.Close, acQuitSaveAll
You can try adding the following to the login form.
DoCmd.Close acForm, "login screen", acSaveYes
This may stop Access from thinking it needs this form. It may not. Just an idea to replicate opening and closing the form.
If the acPrompt is offering you information in the Docmd.Close, you may vary well have to address the root caused described before any option here will work in RT. I don't know what a login form may be doing other than being a simple unbound form. You can check the properties and disable things.
Again. Approach one change at a time. You can adjust the properties of your login form so it does not allow edits, adds, DS view, pivot table, design view, etc. Dumb it down. Default view should probably be Form view.
I hope this helps to shed some light. Let me know what you get.