I am using dictionaries and collections in VBA, and I have a problems
whenever there is an error and I have to stop the code execution I
loose the contents of these data structures. I come from a c++
background and to get around this sort of issue I would use persistent
data structures. Is there anything like this in VBA?

Thanks
Tom

If declared at the module level (outside any procedure), they are persistent
unless you hit the reset button or use the END statement.

Beyond that, I can't think of another in memory solution.

--
Regards,
Tom Ogilvy


" wrote:

I am using dictionaries and collections in VBA, and I have a problems
whenever there is an error and I have to stop the code execution I
loose the contents of these data structures. I come from a c++
background and to get around this sort of issue I would use persistent
data structures. Is there anything like this in VBA?

Thanks
Tom

On 10 Sep, 13:00, Tom Ogilvy
wrote:
If declared at the module level (outside any procedure), they are persistent
unless you hit the reset button or use the END statement.

Beyond that, I can't think of another in memory solution.

--
Regards,
Tom Ogilvy

" wrote:
I am using dictionaries and collections in VBA, and I have a problems
whenever there is an error and I have to stop the code execution I
loose the contents of these data structures. I come from a c++
background and to get around this sort of issue I would use persistent
data structures. Is there anything like this in VBA?

Thanks
Tom

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

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

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

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