ISTAT('MEMORY') returns a number for me using a Win2K workstation under both
RB6.5++ WIN & DOS.  The number returned by 6.5DOS seems to reflect actual
memory installed, the number under 6.5WIN is usually 120,828 (using various
computers with different amount of memory installed).

The ISTAT('TOTALALLOC') function causes a crash in RBG65.exe when running
RB6.5++ (Win) on a WIN2K workstation. 

I was just suggesting that you might use the ISTAT('MEMORY') function to
pinpoint where the problem was in your crashing form.

The "FIX" would be a short term solution to get the app working until
someone discovers where the problem really is.  

I had form problems in RB6.5+ (DOS) that seemed to go away when I upgraded
to RB6.5++ and SP2.  I got it to work (prior to the upgrade) by starting
RBase with "START /BELOWNORMAL RBASE65..." 

It seems like slight variations in the computer setup/configuration causes
various people to experience problems that others don't experience.  It hard
to compare apples with apples when your basket contains variable quantities
of 10 different kinds of apples.

Also, network people sometimes fiddle with the network (to improve it?)
without informing the "programmers", so that code that worked yesterday may
not work as expected today (AKA, coding against a moving target).

----------------------------------------------------------------------------
------------ 

-----Original Message-----
From: Crued @ Crued.net [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 28, 2001 2:46 PM
To: [EMAIL PROTECTED]
Subject: RE: Rbase crashing


Does ISTAT('MEMORY') work under Win2K/NT Kernel?  I've tried to write code
using it and it has never returned a number other than 0.

Even so, that is definately a sloppy fix for a *major* memory leak in the
application.  Considering the 16-bit OS is more dead today than yesterday, I
think some time should be spent by RBTI to figure this problem out.  If it
is being worked on, I'd really enjoy to hear something about these efforts,
rather than hearing how Microsoft is to blame because they're going 32-bit.



Reply via email to