check if a recordset is open

[checkOut]

I play around with some code in Access 2002

Public Sub CheckSeveral(strRef as string,....)
Dim rst1 as new adodb.recordset, rst2 as ...

'some code
exit_proc:
Here the trouble start.
I will be sure all my recordsets are closed and deleted
I'll try the following
If rst1.open then
rst1.close
end if
if rst2.open etc...

set rst1 = nothing
set rst2 = nothing etc.
End sub
But rst1.open is not the valid procedure, anyone knows how to check for open recordsets?

Thnx in advance,
gerard

 

[GHolden]

You can use...

'test for closed
If rst1.State = adStateClosed Then

'test for open

If rstTest.State = adStateOpen Then

There are two ways to write error-free programs; only the third one works.

 

[Harpz]

You can also use the recordcount, if a value is returned then your set is open, if an error occurs then it is closed.

There are four ways.

 

[checkOut]

Thanx both,

this was what I need
Gerard

 

[FirstAndGoal4]

"You can also use the recordcount, if a value is returned then your set is open, if an error occurs then it is closed."

No offense Harpz but that is not a very good solution. Not only do you incur the overhead of error handling by doing it this way, you would probably catch heck from your manager. If there was no other way I would say OK but when you have a viable solution as posted by GHolder, go with it. Don't cause errors if you don't have to.

 

[Harpz]

FirstAndGoal4,

Point taken when considering it may not be a viable idea to trigger errors, however, error trapping and err handling is not and never will be an overhead. All industry standard systems must have error trapping when the code is written by a developer.

 

[GHolden]

Harpz,

As with FirstAndGoal4, no offence ment.

I agree that "All industry standard systems must have error trapping when the code is written by a developer."

However the execution time of an error handler in this example, especially by the time you've checked the error and performed the related tasks would be significantly longer.

Also, to someone reading the code, it would not be as obvious what was actually going on. If you read someones code you assume the error handlers are to trap errors, not to be used as an integral part of the functionality of the code.

I admit it's sometimes unavoidable, but in my opinion should only be used as a last resort.
There are two ways to write error-free programs; only the third one works.