On 10 Sep, 14:22, barnabel wrote:
I don't think he is using an END statement. He is pressing the stop button
in the VBA debugger.

The more important question here would be what errors are you getting that
you are not handling properly and need to stop execution to fix?

"Robert Bruce" wrote:

That is the problem, often I do have to hit the END statement and so
loose the state. I am toying with the idea of using ADO record sets
wrapped in a class. Essentially it would use the users temp directory
to store some sort of file representation of data objects. This would
mean that even if the VBA code execution is stopped ( i.e. END called)
the objects could recover their data from the persisted files. The
drawback with this is I would have to work out the time efficiencies
of the storing and lookup as well as re-initialisation

Tom

Use of the END statement has long been frowned upon by VB developers because
of the way it works. It's like throwing a grenade at your PC - your code
execution will finish for sure, but there are tidier ways to do it.

Rob

Well as the code is very much in development still it can be anything
from incorrect code, to changes resetting the VBA.

Each time this happens at the moment I just reload all my data from
file. I am looking for a way to do this under the covers. My idea is
to have a persistantDictionary class that will be a wrapper around a
dictionary, and on modification of that dictionary will stream changes
out to file. It will then recover from this file in the event of a
restart

Tom