Sounds like it is a memory issue. My guess is that the JPG component is rendering the images as BMPs in RAM. If you have lots of images in a report, they probably use up the available memory and then start swapping to disk. That could explain the progressive slowing.
Use a memory profiling tool and see if that is the problem. Do you have source code to the RAVE components? That can be enlightening. Go to 64 Bit Windows and add more RAM? I use D2010 and RAVE 8.0.1, so I can't help much more than this. --- In delphi-en@yahoogroups.com, "Brad Hall" <brad.h...@...> wrote: > > Hi everyone, > > I'm using D7 Ent, Rave 5.1.3 + the ndcsJPEG component that allows jpeg's > to be used on Rave Reports. I'm also using the ndcsGreenBar, but I don't > think that's causing my issue. > > I've created a report in Rave, connected to a datasource, which displays > 5 fields + 1 image per row, rendering to PDF. > > When the PDF is created there are a total of 18 pages, with approx 8 > rows per page. > > When I preview the report thru Rave designer, the pages are generated > quickly enough. > > > > In Delphi, I have the rvProject, rvSystem, rcDatasource, rvRenderPDF > components. It is also an Intraweb app using the stand-alone web server. > > When I generate the report thru my app, the report generates the pages > quickly enough until it starts generating page 13. > > Page 13 can take (literally) 3 minutes, then page 14 will take 4 > minutes, page 15 will take 5 minutes, etc etc. > > > > I created a test Windows app (not Intraweb) thinking it may have > something to do with the web server, but I got the same result. > > I tried using rvNDRWriter, streaming it + then rendering to PDF, but > still got the same result. > > I then created a different test Rave report without images + it > generated the PDF quite fast. > > I couldn't really find any info about it on the web either. > > > > So I've reached the conclusion that the images on the report > (ndcsJPEG...) are most likely creating the problem. > > > > Has anyone else had this issue, or know how it might be circumvented? > > > > Thanks :-) > > > > > > Brad. > > > > [Non-text portions of this message have been removed] >
