treeview crashes access after n recordset-changes

[Volker Neurath]

Hello all,

I developed a small database for storing information about quotations (i.e.
when typed in, who is the responsible field-staff-member, for which
distributor for which reseller and who is the final customer).
The database ist necessary to compensate missing capabilities in our main
tools.

Now, i tried to build up a kind of a verson-history fpr quotations; this ist
possible because in our database we also store the predecessor of any
quotation, and a project-number (in our case the project-number is
identical to the number of the very first quotation, opened to a new
project)

I did so some weeks before - with a listbox. That works fine up to now, but
is both, not easy and not fast to read.
So my intention was to do it with a treeview-control.

Hint: the listbox history is programmed in a way, that the box only show the
history of the actual recordset and as i said above, it works fine, but
difficult to read (non-intuitive )

So i placed another tab in to my tab-control an an this empty tab i placed
the treevie-control.
This treeview is filled by a recursive function - works fine, the data shown
on the control seems to be ok up to now.

My Problem: changing between recordsets and then opening the Treeview-Tab,
causes a crash of Access sooner or later. and this is reproduceable.

Anybody out there, with an idea *what* causes the crash?

What do you need for giving hints?

If code is needed: please inform men, but i won't be able to post the
function or any other code until monday - at home i do not only not use
MS-Office but not even windows

Volker

 

[Piet Linden]

Hello all,

I developed  a small database for storing information about quotations (i.e.
when typed in, who is the responsible field-staff-member, for which
distributor for which reseller and who is the final customer).
The database ist necessary to compensate missing capabilities in our main
tools.

Now, i tried to build up a kind of a verson-history fpr quotations; this ist
possible because in our database we also store the predecessor of any
quotation, and a project-number (in our case the project-number is
identical to the number of the very first quotation, opened to a new
project)

I did so some weeks before - with a listbox. That works fine up to now, but
is both, not easy and not fast to read.
So my intention was to do it with a treeview-control.

Hint: the listbox history is programmed in a way, that the box only show the
history of the actual recordset and as i said above, it works fine, but
difficult to read (non-intuitive )

So i placed another tab in to my tab-control an an this empty tab i placed
the treevie-control.
This treeview is filled by a recursive function - works fine, the data shown
on the control seems to be ok up to now.

My Problem: changing between recordsets and then opening the Treeview-Tab,
causes a crash of Access sooner or later. and this is reproduceable.

Anybody out there, with an idea *what* causes the crash?

What do you need for giving hints?

If code is needed: please inform men, but i won't be able to post the
function or any other code until monday - at home i do not only not use
MS-Office but not even windows

Volker

one thing that could be happening is that you are not closing
recordsets and destroying object references. As a result, after a
while, the unreleased resources being used up by your form cause
Access to run out of memory resources and crash. My guess would be to
post the code that populates the listbox (and maybe the tables) in the
form that you are having problems with. The one thing I would
definitely look for is code where you open recordsets but do not close
them and set the pointer to the recordset to nothing. That would
definitely cause memory leaks.

As a general rule of thumb, *always* close the objects you open, and
if you set a reference to an object, dereference it in your code and
your error handler.

For example, if you have this in your declarations section:

dim rs as ADODB.Recordset

set rs = <whatever>

then you should also have

rs.Close

and later

Set rs=Nothing

In *theory*, ADO cleans up after itself, but it's always better to do
it explicitly. A bit more work, but it eliminates the likelihood of
memory leaks.

 

[Volker Neurath]

Access to run out of memory resources and crash. My guess would be to
post the code that populates the listbox (and maybe the tables) in the
form that you are having problems with. The one thing I would
definitely look for is code where you open recordsets but do not close
them and set the pointer to the recordset to nothing. That would
definitely cause memory leaks.

Ok, I will post the code - tomorrow. Here at home I don't even use
Windows

dim rs as ADODB.Recordset

I still use DAO

set rs = <whatever>

then you should also have

rs.Close

and later

Set rs=Nothing

Hm.. closing and dereferecing ist what I do in my code.

OK, i'll see.

Volker