But I eventually figured it out….

Assuming you have a subreport control on a parent report called MySubReport and you want the subreport control to be not visible should it have no records, this is one option you can use.

Private Sub Report_Activate()
If Me.MySubReport.Report.HasData = False Then
Me.MySubReport.Visible = False
Else
Me.MySubReport.Visible = True
End If
End Sub

Report.hasData is the key!

Many solutions on the Internet talk about using code like this in the IF..THEN expression:

Me.SubReport.Form.RecordSet.RecordCount = 0

Of course, that won’t work (we’re working with reports not forms and Microsoft inform us that the recordset object isn’t available in reports. If you try use the above, Access will keep throwing you errors like:

This feature is not available in an MDB.

I’ve tested this in Access 2007 and it seems to work fine.

For example if I open up a database using something like this

Dim db as dao.database
Set db = currentDb

I will close it at the end of the function or procedure

Db.close
Set db = nothing

When using transactions, you make use of the workspace collection and you open it along the lines of

Dim myWrk as dao.workspace
Set myWrk = DBEngine.Workspaces(0)

As usual, I want to close this at the end of the procedure along the lines of

myWrk.close
set myWrk = nothing

This is were I went wrong

I was looping through a DAO recordset to check for conditions then make updates to a table. I wanted to make sure things didn’t screw up half way through so implemented some transactions, and then I started getting an error message

Run-Time Error ‘3420’:
Object Invalid or No Longer Set

Specifically when I tried to use the .moveNext method of my recordset.

I began to tear my hair out! Google talks about updating my jet version, but that wasn’t the problem at all – I knew that I had the most up to date Jet engine.

It took me some time and a bit of research but I figured out it was happening when I made a call to another procedure while inside the recordset. Looking through the code, and nothing was wrong. I even pasted the code of the sub-procedure into my main procedure (minus all the variable setting and clean up objects stuff) and it work. Something was up in my sub procedures.

It was eventually a comment in this article on transactions at Allen Browne’s excellent Ms Access tips website – I was explicitly closing the workspace. This is apparently a no-no. I deleted the .close line of code, and voila, it all worked!

Occasionally, Access can act rather confusingly. I ran into a typical example early this morning, when I was trying to get Access to allow entry of percentages correctly. I’ve done this about one thousand times before and probably solved this problem one thousand times as well, but every time it happens it causes me to scratch my head (mostly in disbelief).

What happens is this: You set up a field in a table, designate it to be formatted as percentage. Right OK – you go to your form design, set up your input fields, and then try to enter a number as a percentage, and notice that it keeps rounding to 100% or 0%. Frustration ++.

Back to table design. The problem here is that you have to correctly set the field data type as well as the data type format. However, the data type is not integer, double, or even decimal – it is usually single. Once you set that on your percentage fields, you can enter data in decimal format (i.e. 0.5, 0.25 etc etc) and it will show up in its proper percent format.

I know this is shouldn’t be a problem but, amazingly, people get caught by it all the time, and there doesn’t seem to be clear answers on the web. Hopefully this tip does something to addressing this issue.