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.
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
You haven't given enough information for anyone to make a guess.
Dan
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
"contributor" <DONO...@msn.com> wrote in message
news:O5wltqHA...@TK2MSFTNGP06.phx.gbl...
it is sadly about the 2GB limit
fox IS finally DEAD!!!!!
not because it couldn't be fixed
rather itis because it WON'T
> fox IS finally DEAD!!!!!
Wot AGAIN!
regards
Alan
> *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
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
And happens with a clean install of SP2 as well...
sigh
thomas