I let the system choose its own setting so I'll try fixing it. Thanks for the guidelines.
And for your follow-up reply , Albert, with one report using only the breakpoints and the other using an additional sort I assumed that that was not the problem. That said, I think I am beginning to feel the same way - if only so that no conflict can arise. Regards, Alastair. ----- Original Message ----- From: "Albert Berry" <[EMAIL PROTECTED]> To: "RBG7-L Mailing List" <[email protected]> Sent: Tuesday, February 22, 2005 5:36 PM Subject: [RBG7-L] - Re: Problem with reports (continued...) > Alastair, thinking back to older days, I suggest you tell MS what to use for virtual memory. I > have done this, sometimes with spectacular results, sometimes with spectacular failure. I do know > that it invariably cuts down on some of the disk thrashing just before the blue screen. > > In the virtual memory settings, the MIN and MAX values should be the same. The OS doesn't have to > continuously increase and decrease the size of the virtual memory block on the drive. This also, > depending on the operating system and disk condition, reduces the fragmentation of the virtual > memory block. > > The size of the virtual memory should not exceed 4x the physical RAM, nor should it be less than > 2x, for optimal results, if I remember correctly. This does not mean that you can not use larger > sizes, but we (a group of us old farts) have found that going past 4x sometimes has the opposite > effect of that desired. > > The key item seems to be that the virtual memory should be a fixed amount. > > --- Alastair Burr <[EMAIL PROTECTED]> wrote: > > > 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. > > > > Javier > > > > > ===== > Albert Berry > Management Consultant > RR2 - 1252 Ponderosa Drive > Sparwood BC, V0B 2G2 > Canada > (250) 425-5806 > (250) 425-7259 > (708) 575-3952 (fax) > [EMAIL PROTECTED] >
