By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,222 Members | 1,123 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,222 IT Pros & Developers. It's quick & easy.

Finding pointers to recordsets inadvertently left open...

P: n/a

Is there any way to walk thru memory to find a variable that holds a
reference to a recordset that has been left open? (I use ADO for my

The reason I want this info:

I am writing code to compact back end files.

If all recordsets, bound forms, combo boxes, etc are closed, the lock
file for each back end db should be automatically deleted (is this
correct?). If so, I can compact the back end databases from the front
end using the compactdatabase method.

However, I close all my forms, but still one of the lock file lingers

The only reasonable hypothesis, seems to me, is that a recordset has
inadvertently been left open. Is this so? And how to discover the
rogue variable and correct the code that left it open... or do I have
to plod my way thru all my ugly code?

At present I have to do the compact and repair in the startup
procedure of the app, which will add to startup times, so not ideal.


Andrew Wrigley
Nov 12 '05 #1
Share this Question
Share on Google+
2 Replies

P: n/a
if you have links to the tables in the BE....there is your lock.
try to compact from an external application
Nov 12 '05 #2

P: n/a
Thanks the good intentions, but sorry, you are wrong.

The links to the BE will only cause an .ldb file to be opened IF there
are bound forms currently open that use the linked tables.

My problem is that the links are left open EVEN after closing all
bound forms.

In fact, I have solved the problem by plodding thru the code. For
reasons that escape me, a sub that I used to modify the sql of a query
using adox was causing the problem.

I changed the code to use ado, and all is now as expected. However,
in the UK Access User Group someone said that they had the reverse
problem, ie, when they changed from dao to adox the problem went away.

Ah, well, if this job was easy I would be paid less.

Thanks all the same.

Andrew Wrigley
Nov 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.