Hello Judy,

I would check any worksheet event code you might have. A command
button can be "clicked' in code by setting its value property. You
could also add a break points to each line in LoadDataExit to step
through and verify your operations. To add/remove a break point, place
the cursor on the line and press F9. To step to the next statement,
press F5.

Sincerely,
Leith Ross

Per JHop:

FWIW, I've seen similar situations in my own MS Access VBA.   Not
resulting in a loop.... but definitely branching to someplace not
specified in the code.... maybe 2-3 occurrences... and they've
all been at the Exit point.

Three things come to mind. First, is it possible that in the code you
<snip>ed you have some error handling code that is causing the execution to
jump to another location within the sub (or to a parent sub which calls the
problematic code)? Second, are you ever setting the Value property of the
cmdLoadData button? Doing so will cause the Click event to run. Finally, it
could be that VBA's own internal code storage has become corrupted or
otherwise damaged. The solution to this problem is to export all code out of
VBA to plain text files, remove the code modules from the project, which
causes VBA to purge its storage areas, and then import the text files into
VBA, starting VBA with a clean slate. Rob Bovey (www.appspro.com) has
created an Add-In called Code Cleaner 5.0 that automates the entire
export/remove/import process down to a few mouse clicks. It also makes a
backup copy of the workbook prior to removing the code so that in the very
rare chance that something goes wrong during the export/import process.
Cleaning out VBA's code storage can cure a wide range of very strange
problems.

See Rob's page at http://www.appspro.com/Utilities/CodeCleaner.htm for a
free copy of the Code Cleaner. This add-in is a must-have for serious VBA
developers.

On a final note, when debugging your code, you should set error trapping to
"Break In Class Module" on the General tab of the Options dialog in the VBA
Editor.  If an error occurs, this will break at the actual line of code that
caused the problem. If the problem lies in an object module (userform,
class, etc), and error trapping is set to "Break On Unhandled Errors", the
code will break on the line of code that refers to the object module rather
than on the actual break. As an example, suppose you have in a user form the
line

Debug.Print 1/0 ' obvious error

And in a standard module you have UserForm1.Show. If error handling is set
to "Break On Unhandled Errors", to code will break on UserForm1.Show, even
though nothing is wrong with the Show method itself, rather than on the real
error within the form Debug.Print 1/0.