Hey Eric, Testing was with Comcomp as that is the requirement for RBTI to replicate.
Apparently, Mike was able to replicate the ZIP RETURN leak trigger using that DB and my sample code. Problem is, the leak does not happen consistently as further testing by me found. But, at least, eliminating ZIP RETURN consistently eliminated the leak caused by each db access. I'm hoping that changing the way RBDOS is started, along with eliminating ZIP RETURN, will produce a less memory hungry situation. I will soon have a test set up to eliminate ZIP RETURN in the large application using an environment variable set in autoexec.rbd to tell the app to skip the ZIP RETURNS placed there to recover lost memory. I should know pretty soon if the memory leaks go away using this startup scenario. It's worth a try, and won't take a great deal of time to set up. Dennis McGrath --- Eric Peterson <[EMAIL PROTECTED]> wrote: > Did Dennis send you the exact database he tested with? If you tested > with ConComp, I wouldn't doubt that there is no problem. That > database > is not even 512k in size. If Dennis is testing with the database I > think he is; that DB is over a GB and has countless indicies. > > > > > > Eric Peterson > > > > _____ > > From: Mike Willochell [mailto:[EMAIL PROTECTED] > Sent: Friday, November 14, 2003 10:01 AM > To: RBASE-L Mailing List > Subject: [RBASE-L] - RE: Virtual Memory Problems, RB65++, Win2K > > > > At 09:32 AM 11/13/2003 -0600, Eric Peterson wrote: > > > > > This has been discussed at great length. Everything you are saying > is > the same thing many of us experience everyday. I personally have no > less than 10 users that have to reboot 2-3 times a day because of > this > problem. Many people have posed this problem to RBase Tech. and > nobody > has been successful getting them to listen and fix it. > > > Dear Steven and Eric; > > This morning I tested an example sent to us by Dennis McGrath on two > separate > machines, one Windows XP and one Windows 2000 Professional. My > results > were consistent on both machines and were contrary to the results > that > Dennis > experienced on his machine. > > Using the following example provided by Dennis, I issued the > following > command > against the ConComp database while monitoring the Task Manager for > its > results: > > SELECT COUNT(*) FROM Customer > > Dennis reported that the memory usage on his machine jumped by 128K > each > time > he executed the command, but my results were an 8K jump on both > machines, even > after dozens of iterations. > > This problem is most likely aggravated by a setting regarding how > Windows handles > the memory because Windows handles most of this in the ntvdm.exe > shell > (NT > Virtual DOS Machine). These settings are accessible by right-clicking > the shortcut > icon and manipulating in there. It is best to make everything that > you > can "Auto." > > See if this has any impact on your results. Otherwise, if someone > could > create an > example utilizing the ConComp database, we will be happy to look into > it. > > Best Regards, > > Mike > >
