[RBG7-L] - Re: Problem with reports (continued...)

[Alastair Burr]

If you're offering to pay for one I'd be delighted <g>.   Regards, Alastair.   ----- Original Message ----- From: Emmitt Dove To: RBG7-L Mailing List Sent: Wednesday, February 23, 2005 1:01 PM Subject: [RBG7-L] - Re: Problem with reports (continued...) Alastair, If you have hardware old enough to be running W98, my best suggestion is to get a new machine with XP installed.  I personally would not attempt to upgrade hardware that old to XP.  A nice 3ghz or so P4 with a gig of ram makes for a very nice platform. Thanks, Emmitt,   Unfortunately I can't test it on XP. I've been tempted to upgrade 2 or 3 times but the "blurb" doesn't seem to offer anything new that I need and I am loathe to upgrade rather than install from scratch.   Maybe it's time to bite the bullet and upgrade anyway but the thought of not being able to get XP to work with my hardware frightens me more than running the reports twice and editing them together - and I can set-up a Word macro to do that.   Regards, Alastair.   ----- Original Message ----- From: Emmitt Dove To: RBG7-L Mailing List Sent: Tuesday, February 22, 2005 5:21 PM Subject: [RBG7-L] - Re: Problem with reports (continued...) Alastair, The thrashing I am describing happens when all Windows resources are consumed and the OS has moved nearly all of itself out to disk (VM).  It wouldn't matter what else was running --- that, too, has been moved off to disk. You also know that RBG7's resource requirements exceed those of 6.5++; the balance may have been tipped.  Do you not have the ability to test this on a w2k or XP machine? Thanks, Emmitt, David & Javier. Just to confirm that the database has just been reloaded after installing the latest beta and I'm sure that the sort matches the breaks on that report. I understand what you're saying about resources, Emmitt, but I would expect the point at which the report "stops" to vary with whatever else is running - not much, usually - but, in both cases, the reports stop at the same point each time. Also, both reports in their v6.5 format run against the same data quite happily so it seems to me to be something else. However, are there any changes that I can make to, for example, the amount of virtual memory, that might have any influence? Even a small subsequent change in the result would tend to confirm what you're suggesting. Is there anybody else out there who is still using W98SE and can confirm one way or the other if they have any problems with similarly large reports? Thanks again, Regards, Alastair. ----- Original Message ----- From: Emmitt Dove To: RBG7-L Mailing List Sent: Tuesday, February 22, 2005 2:16 PM Subject: [RBG7-L] - Re: Problem with reports (continued...) Alastair, I think the key here is your platform.  RBG7 likes to have adequate resources, and for our application I recommend a minimum of 512 mb on at least w2k if not XP.  W98 likely isn't up to the task.  You are probably getting to the stage where W98 starts disk thrashing - the application program requires more memory, so it requests it from the OS.  The OS has to swap some application memory out to disk in order to load the part of the OS required to service the request, and in the process takes memory away from the application that was just requesting additional (virtual) memory. We had a reporting application running against a very large database in R:Base for DOS some years back on W98.  When we hit this barrier you could hit ctrl-esc and it would take up to 45 minutes to get back to the desktop.  Under w2k it works just fine, thank you. Alastair I bet Emmitt is right - he usually is - but just in case, what you're describing would also be consistent with damaged indexes.  Backup the database Do a PACK KEYS on the database See if that makes a difference David Blocker [EMAIL PROTECTED] Also, make sure that the ORDER BY clause in your statement does not conflict with the breaks in the report; I found that if you want to use and ORDER BY clause in your statement, it must include first the exact order of the breaks and then the additional sort.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> Javier Emmitt Dove Manager, DairyPak Business Systems Blue Ridge Paper Products, Inc. 40 Lindeman Drive Trumbull, CT  06611 (203) 673-2231 [EMAIL PROTECTED] [EMAIL PROTECTED] Emmitt Dove Manager, DairyPak Business Systems Blue Ridge Paper Products, Inc. 40 Lindeman Drive Trumbull, CT  06611 (203) 673-2231 [EMAIL PROTECTED] [EMAIL PROTECTED]