Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Error 43 - Not enough Memory to Complete this Operation

801 views
Skip to first unread message

contributor

unread,
Sep 26, 2007, 4:20:31 PM9/26/07
to
Does anyone know what the resolution for this error might be.

The msdn "help" is below:

There is not enough memory to complete this operation (Error 43)
Free some memory currently in use and try this operation again.


Rush Strong

unread,
Sep 26, 2007, 5:48:10 PM9/26/07
to
The easiest resolution is to don't try the operation.

But if it happens to be an operation that you need, then providing a bit
more info - what you're trying to do, for example - might make it easier
to come up with an answer.

- Rush

Dan Freeman

unread,
Sep 26, 2007, 5:28:29 PM9/26/07
to
It can mean a variety of things, including in some instances having TOO MUCH
memory available.

You haven't given enough information for anyone to make a guess.

Dan

contributor

unread,
Sep 26, 2007, 7:41:41 PM9/26/07
to
The problem seems to have been related to a corrupt memo file.

So, the question is, how do you minimize memo corruption?


Dan Freeman

unread,
Sep 26, 2007, 7:54:13 PM9/26/07
to
contributor wrote:
> The problem seems to have been related to a corrupt memo file.
>
> So, the question is, how do you minimize memo corruption?

* Make sure the power supply is conditioned.
* Make sure users are not abending out of your application.
* Make sure the network is stable.

Memo field corruption generally comes about from environmental conditions. A
flaky NIC or hub can cause bits to get lost going over the wire. If the
power goes out, data that was cached and not yet written to disk can be
lost. etc.

And, the ever popular big red switch used to shut down your application is
almost a guarantee of corruption.

Dan


Anders Altberg

unread,
Sep 27, 2007, 7:45:28 AM9/27/07
to
There was a thread on this isssue in
microsoft.public.fox.programmer.exchange, April 29, 2007 with postings from
Christof Wollenhaupt and Olaf Doschke int al.

-Anders

"contributor" <DONO...@msn.com> wrote in message
news:O5wltqHA...@TK2MSFTNGP06.phx.gbl...

contributor

unread,
Nov 27, 2007, 6:32:48 PM11/27/07
to
I found out the cause

it is sadly about the 2GB limit

fox IS finally DEAD!!!!!

not because it couldn't be fixed

rather itis because it WON'T


Alan Pengelly

unread,
Nov 28, 2007, 9:12:00 PM11/28/07
to
In article <#dvsO3UM...@TK2MSFTNGP06.phx.gbl>, DONO...@msn.com (contributor)
wrote:

> fox IS finally DEAD!!!!!

Wot AGAIN!

regards
Alan

Dan Freeman

unread,
Nov 30, 2007, 4:03:19 PM11/30/07
to
Fox was announced dead when SP2 was announced as the last release.

Alan Pengelly

unread,
Dec 1, 2007, 2:48:00 AM12/1/07
to
In article <#100uR5M...@TK2MSFTNGP06.phx.gbl>, sp...@microsoft.com (Dan Freeman)
wrote:

> *From:* "Dan Freeman" <sp...@microsoft.com>
> *Date:* Fri, 30 Nov 2007 13:03:19 -0800


>
> Fox was announced dead when SP2 was announced as the last release.

I thought the announcement said that it would be supported until 2014

regards
Alan

Thomas Ganss

unread,
Dec 1, 2007, 4:10:52 AM12/1/07
to
Dan Freeman schrieb:

> It can mean a variety of things, including in some instances having TOO MUCH
> memory available.
>
> You haven't given enough information for anyone to make a guess.

I have been running into this one in the last 10 days as well:
after a few H of datamunging of insurance data a:
select * from ... into array ...
throws error 43 if reccount is about 80000 recs or greater, fcount() =
29. (No, this is not "my" code <g>).

_Tally shows the correct no. or records if I surround the select with
try... catch (verified via select Count(*) before).

The same table at startup can be read without a problem.
Flush, sys(1104) and different sys(3050) settings make no difference
when called directly before the crashing statement:
even adding much more memory in sys(3050) than sys(1016) shows at
program start is needed for the operation does not help.
Yes, I have also tried elevating sys(3050) by 128MB just before the
select to stay under 500 MB afterwards.

Working with try catch and asserts before the line and simple
dimension[_laErgCount, fcount()] creates the error as well -
slightly lower amounts of array fields [_laErgCount, 23] succeed.
So current assumption is that allocating memory for the empty array
is the problem. Don't know if memory space needs to be unfragmentet for
the dimension[], but trying to make sure of that via sys(3050) does not
help.

Running under XP and vfp9SP1, testing with SP2 is under way.
Yes, I agree that such a select is bordering on abstruse,
but Error 43 should not happen on 3Gig machines when I try to help vfp
by trying different sys(3050) settings after the "no limits" talk on
vfp9<g>.

regards

thomas

Thomas Ganss

unread,
Dec 4, 2007, 12:22:25 PM12/4/07
to

>
> Running under XP and vfp9SP1, testing with SP2 is under way.

And happens with a clean install of SP2 as well...

sigh

thomas

0 new messages