Access 2002 bloat using Printer object

[Rick Collard]

I have been experimenting with the new Printer object in Access 2002
and discovered some unexpected database bloat. Simply assigning the
same value to a property of a report's Printer object will cause the
database to grow. Here's my test code:

Public Sub ChangeReportSettings( _
sReport As String, _
sDeviceName As String, _
Optional nIterations As Long = 1)

Dim rpt As Report
Dim i As Long

For i = 1 To nIterations
DoCmd.OpenReport sReport, acViewPreview
Set rpt = Reports(sReport)
rpt.Printer = Application.Printers(sDeviceName)
rpt.Printer.Orientation = acPRORLandscape
DoCmd.Close acReport, sReport, acSaveYes
Next i

End Sub

I thought some growth would be understandable if, for example, the
report's printer is changed from the default to a specific printer.
However, after the first iteration there really should be no change to
the report. It's not about changing the printer either. I commented
that line out and the database still grows just by setting the print
orientation over and over. What's going on here? Any ideas?

Rick Collard
www.msc-lims.com

[Larry Linson]

"Rick Collard" wrote >

What's going on here?
Obviously, some memory leakage.
Any ideas?

None for avoiding it, except to set your Report object to Nothing when you
are finished with it.

To help, apply all the Service Packs and Patches, and, as with any other
bloat, regularly Compact the Database.

Larry Linson
Microsoft Access MVP

[Rick Collard]

The solution is to not perform the property assignment when there will
be no change to the property's value. Unfortunately, Where I could
have been succinct:

i = 1

I now have to be verbose:

If i <> 1 Then i = 1

just to avoid the bloat.

Rick Collard
www.msc-lims.com

On Thu, 11 Sep 2003 23:57:01 GMT, "Larry Linson"
<la**********@ntpcug.org> wrote:

None for avoiding it, except to set your Report object to Nothing when you
are finished with it.

To help, apply all the Service Packs and Patches, and, as with any other
bloat, regularly Compact the Database.

Larry Linson
Microsoft Access MVP

[Rick Collard]

On Fri, 12 Sep 2003 18:19:29 GMT, dX********@bway.net (David W.
Fenton) wrote:

The solution is to not perform the property assignment when there
will be no change to the property's value. Unfortunately, Where I
could have been succinct:

i = 1

I now have to be verbose:

If i <> 1 Then i = 1

just to avoid the bloat.
Why is this bad?

It's not bad. Where I just wanted to set a property value, it struck
me as inefficient to first test the value of the property.

I guess because of my replication experience I'm used to doing this
with data:

If Me.Dirty Then Me.Dirty = False

(in a replicated database this can result in lost data because
conflicts are resolved in part based on most generations of saves
in a record)

And I don't see that the time it takes to do the test is wasted as
If/Then is short-circuited so you're really not executing any more
lines of code. Indeed, you're probably speeding up your code as
testing the value probably takes less time than writing it.

Good point. I haven't run timing tests but given the bloat you're
probably correct that the code actually executes faster without
unnecessarily assigning values to the properties. I am annoyed by the
bloat but I'm just nitpicking when it comes to the appearance of the
code.

Rick Collard
www.msc-lims.com