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]
