Problem with Basic Use of Requery

[Pat Hartman]

I disabled the Option Group control that I was using to frame the subform.

I don't know where you were going with this but subforms don't need "framing" so get rid of the Option Group and just put the subform on the main form directly. Or, use a tab control and put the subform on the desired tab page.

Anyone care to take a crack at explaining the bizarre behavior I was experiencing with the first several "fixes" that didn't stick beyond the current session?

Did you at some point set warnings off and forget to set them back on? With warnings off, Access will silently discard changes if you close an object without specifically saving it first. To avoid this problem, I always use a macro to set warnings off. The macro turns the hourglass on and warnings off so if my code stops and I forget to turn the warnings back on, my cursor will be an hourglass providing me with a visual clue that warnings are off. The second macro turns warnings on and the hourglass off. You could of course write the two instructions instead of using macros but the macro provides a bit of convenience if you need to do the off/on outside of a code module.

Anyone care to take a crack at explaining the bizarre behavior I was experiencing with the first several "fixes" that didn't stick beyond the current session?

The subform CONTROL needs a SourceObject to specify which form it contains. A main form does not have a SourceObject.

Likewise, I haven't figured out a successful strategy for navigating the in-app help system

Access help has been getting steadly worse since A97. It's gotten to the point now that you can hardly get syntax using it let alone guidence. There is better organized documentation in the MSDN library.

I simply set the "Source Object" to the appropriate table (from a dropdown list).

Bad move. Everything user facing should be a form or report. You don't have events with tables and queries so you can't do anything to protect the user. Take the time to make a form. You can use the wizard to generate one that looks like a datasheet if that is the look you are going for but it will give you all the control you need. This may be the root of all the problems you have been having.

In general I feel that you are over-thinking this. Access is a rapid application development environment and common things such as subforms on mainforms don't require custom code to function correctly. Don't spend a lot of time trying to figure out how you can encapsulate things, you'll give yourself a headache. Forms and Reports are class modules and work somewhat they way you would expect as you enstantiate them but going beyond that goes against the natural flow in an Access app and will lead to thousands of lines of useless code and lots of work for no gain.

 

[BobbyGraves]

Thanks guys for you input.

Pat, thanks for you insight and suggestions. I haven't been doing anything with warnings. I did have an unusual implementation of the subform (it wasn't actually a form in the object list), but I later changed that to a more typical implementation...not that that fixed things by itself. In absence of an explanation on how my code change served as a solution, I tend to agree with mdlueck's assessment of Access being Access. Other than that, I'm probably just making things hard on myself because I pushed forward in development despite the fact that I've forgotten most of what I used to know. I probably should have approached it like I was designing in Access for the very first time.

Anyway, thanks again. Please feel free to close this topic.