What did I do today? I have a complex order form I built according to customer specs. They have several different scenarios and ways in which they can open an order in the form and I did not build the form so that it is capable of opening multiple orders at once. In retrospect, that would be a great idea. I think in order to do that I would have to create some way in which the multiple temp tables used for each form would either be able to be specifically created for each form or be separated in a way in which to differentiate each form. Anyway, that was beside the point in which I was writing about today.

This single form might need to be closed and reopened with a new order to display. In particular when the situation is that the user is quickly viewing different orders and switching between them.

So the way I solved this in the past was to write a single routine for opening the form that would try to save the existing order. If it was unable to save changes that were being made, it would send the user to the form to finalize the changes themselves. I ended up using a DoCmd.Open VBA command to bring the form to the forefront.

Turned out this was a bad idea. It worked when I was testing, likely because I had created new orders during the testing process, but in the wild, it was very easy to make the routine fail. If you were only editing old orders, the DoCmd.Open would reopen the order form to the very first record in the recordset, whatever that happened to be. If it was an invalid order, you would get lots of ugly error messages and freak the user out.

So the simple solution to this was to use the Forms(“order”).SetFocus() method, which brought the existing form to the forefront as is without attempting any kind of loading logic.

It’s amazing to me how easy it is to use commands and functions in a way that simply does not work as you expected.