HTML Report causing unrecoverable, non-responsive

[WalkaboutTigger]

One challenge I am having is, when comparing two large directory trees, exporting the report as HTML fails, causing ExamDiff to become unrecoverably non-responsive.

What meaningful information can I provide to help solve this issue?

The directory trees in question complete the compare process successfully.

Each directory tree contains approximately 30,000 sub-directories and 240,000 files.

Thank you,

WT

[psguru]

Please contact us via the form at http://www.prestosoft.com/ps_email.asp . We'll send you a special build that should help us debug the problem.

[WalkaboutTigger]

Form completed and sent.

I do receive an "Out of memory" pop-up while trying to generate the html report. Also, when these errors occur, the html file exists but is 0 length, as if the application is trying to build the entire file in memory rather than dumping the code to the file as it is generating it. If it really is trying to generate the entire file in memory, I recommend changing that as some of the reports it generates (and yes, I do need them this way) are enormous.

ExamDiff Pro is an excellent product, by the way. I've used it for 3 weeks and find it to be a best-of-class product.

WT.

[WalkaboutTigger]

And two other, related issues:

When saving the text version of the diff file, the file does not contain all of the columns in the diff display - how do I get the time/date stamps and attributes listed in the text file?

When attempting to use the "Copy as text" function of 2,656 files, the program minidumps on me and closes. I was trying to do this because neither the HTML export works nor does the text export have all the information I need for a report I need to get out in 10 minutes! A R G H ! ! ! ! !

Thanks

WT

[psguru]

Form completed and sent.

Thanks, we'll analyze the trace.

I do receive an "Out of memory" pop-up while trying to generate the html report. Also, when these errors occur, the html file exists but is 0 length, as if the application is trying to build the entire file in memory rather than dumping the code to the file as it is generating it. If it really is trying to generate the entire file in memory, I recommend changing that as some of the reports it generates (and yes, I do need them this way) are enormous.

Yes, EDP creates HTML reports in memory first. So far this hasn't been an issue, so we didn't bother to split the report.

Are you sure you need the whole thing? Is it possible that you only need, say, differences, in which case you could apply a view filter before saving the HTML report?

When saving the text version of the diff file, the file does not contain all of the columns in the diff display - how do I get the time/date stamps and attributes listed in the text file?

You don't get them in the text report. This report is similar to the UNIX diff report for directories.

When attempting to use the "Copy as text" function of 2,656 files, the program minidumps on me and closes. I was trying to do this because neither the HTML export works nor does the text export have all the information I need for a report I need to get out in 10 minutes! A R G H ! ! ! ! !

Could you send the minidump to us? (Although I suspect that it a result of insufficient memory, and the "solution" to the crash then will be a "nice" out-of-memory exception).

[psguru]

After doing some thinking... It may not be a bad idea to use files instead of memory for HTML report generation. We'll see what can be done about this; perhaps the next build of 4.5 will have this change.

[psguru]

Build 4.5.2.2 implements file-based approach to saving HTML reports (which uses very little memory). Please give a try.