Images and Memory

Posted by: dbeve on 4 August 2017, 5:22 am EST

  • Posted 4 August 2017, 5:22 am EST

    I've got some questions about images now because these are problematic for us.  Using a WMF is still not a compressed way of storing an image and can be quite large. 

    Right now, if I have an image that is around 400k (WMF), this image appears to go into memory for each page.  If there is only 1 gig of ram (heck, 2 gigs), the server runs out of memory at about 1000 pages simply because of these images.

    At this point in the game, the moment that images exist (say a corporate logo) on a report, large reports (1000+ pages) are not possible.  Is there anything that can be done about this?  Why must the image be stored on every single page in memory?  Could this be changed to use a better method?


  • Replied 4 August 2017, 5:22 am EST

    <span>I am not aware of any AR2 alternatives for your situation. 

    However, if you are using the exact same image at the exact same location on every page, and you only want to print the report (this will not work for viewing), you could try the following:

    Generate the report without the image.
    Use a custom printing solution (using StartJob, PrintPage, etc)
    Before you print each page, use the DrawPicture method to draw your image onto the page.
    Once the page has been printed, Remove the page that you just printed from the pages collection so that it no longer is retained in memory.

    I have not tested this and this will not work for any scenario other than the one specified above, but I believe this could keep you overhead down.  If you want more details on this, I would prefer to discuss them over the phone (614.895.3142).

    Our .NET product caches repeating images, so I would expect a similar report to take much less memory and be able to generate a larger number of pages safely.  </span>
  • Replied 4 August 2017, 5:22 am EST

    You can save AR2 layouts as RPX files and run those in .NET.  Keep in mind that if you use script, you need to convert to C# script or put the code into VB.NET or C# codebehind.  There are also sever incompatibilites such as the frame control (doesn't exist in AR.NET), the datasource, and images (both available, but need to be re-setup).  Once everything is converted you can run it in .NET. 

    So essentially, you cannot just run AR2 through .NET, but with some conversion work this can be accomplished.
  • Replied 4 August 2017, 5:22 am EST

    Sounds like this just might be possible. I'll let you know if I can get this to work using a demo version of AR.NET.  All 3 of the items you mention here are managable.


  • Replied 4 August 2017, 5:22 am EST

    Can AR2 reports be loaded and viewed in the .NET solution viewer?  I imagine not but you never know...
  • Replied 4 August 2017, 5:22 am EST

    Let me know if you have any questions during this process.

  • Replied 4 August 2017, 5:22 am EST

    Do I ever have some questions.

    Okay.  First a little background.  We save the AR 2.0 report layouts into a SQL Server database using:

        pByte = pRpt.SaveLayout("", ddSOByteArray)

    The database field is an Image datatype and this is no problem in AR 2.0.  In AR.NET, things are handled differently as I expected they would. 

    How was DD anticipating someone might actually load old AR reports into AR.NET if they save them in this format?  I could load up the layout into AR 2.0, save to a file and then load into AR.NET maybe but I would rather not have to save this to a file.  AR 2.0 does not allow for saving of the layout as text to the database explicitly.  AR.NET seems to.  Could you shed some light on how this works?

  • Replied 4 August 2017, 5:22 am EST

    AR2 RPX files are not fully compatible with AR.NET.  Script (VB -> C# script), images, data controls and the frame control cannot be interpreted by .NET and must be re-constructed.  Layouts were never designed to be excecuted in both environments without modifications.
Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels