Insufficient memory for this operation...
Granat Yevgeny
Sometimes I get a message "Insufficient memory for this operation..." in
Delphi projects.
I get this message for years no meter whether I work with InterBase or
Oracle.
I close and reopen Delphi (in the best case) and then I can work some time
(several hours or a couple of minutes) without this message.
If I don't close and reopen Delphi I get the following message:
"Unknown database...".
I know that BDE causes this message.
Are there any tricks to reduce the appearance of this message ?
I know that there are some BDE settings that can help in this case -
what are these settings ?
Thanks,
Granat Yevgeny
P.S. I work with D5 Enterprise and Oracle 8
Craig Stuntz (TeamB)
Granat Yevgeny wrote:
>
> Are there any tricks to reduce the appearance of this message ?
> I know that there are some BDE settings that can help in this case -
> what are these settings ?
SHAREDMEMSIZE 4096
SHAREDMEMLOCATION 0x5BDE
-Craig
--
Craig Stuntz (TeamB) · Vertex Systems Corp. · Columbus, OH
We're hiring: http://www.vertexsoftware.com/careerops.htm#sd
Delphi/InterBase WebLog: http://delphi.weblogs.com
Kelly
I tried changing the settings in the bdeadmin and thought it had solved the problem but it hasn't. The code is fine when I walk through it in Delphi 5 , but run as a stand alone executable I get the Memory error. Any other ideas?
Thanks,
Kelly
Craig Stuntz (TeamB)
Kelly wrote:
>
> I tried changing the settings in the bdeadmin and thought it had
> solved the problem but it hasn't. The code is fine when I walk
> through it in Delphi 5 , but run as a stand alone executable I get
> the Memory error. Any other ideas?
Please be specific when talking about errors. There are *two* possible
memory errors. "Insufficient memory..." means you should increase
SHAREDMEMSIZE. "Shared memory conflict..." means you should either
change SHAREDMEMLOCATION or decrease SHAREDMEMSIZE.
Unfortunately, trial and error is the only way I know of to get this to
work.
Kelly Coker
The error is Insufficient Memory for this operation. This program has been running for 2 years, we recently upgraded our client software for oracle to 8i with an odbc driver 8.01.74.00 - this is when we started getting the errors.
Kelly
Dan Rhea
news:3C0E2E49.F6CA022C@no_spam.vertexsoftware.com...
Hi Craig,
I have been banging my head against this problem as well... I.E.
"Insufficient memory for this operation".
The error always happens when I open a query (TQuery object) to our Oracle 8
database which is on a Windows NT 4 server.
My application is written in Delphi 5 and converts data from an Oracle 8
database (latest Oracle 8i client and management server) to an X-Base type
database (maintainance data to production data conversion). On my Windows
2000 (256MB RAM) system, I always get this error (cranking up the settings
in the BDE delays the error but has never removed it). The system I use for
production data conversions has the BDE from Delphi 5 and is running Windows
98 (96MB RAM). This error has never happened on the Windows 98 system. Our
other Windows 2000 systems (all with Delphi 6) run into this error as well.
Since I have Delphi 4, 5 and 6 installed, the BDE installed on my system is
the one from Delphi 6. Could this be BDE or OS related?
__________________________
Dan Rhea
Windows Programmer
SIRS Publishing, Inc.
(Formerly SIRS Mandarin, Inc.)
Dan Rhea
news:3c0e443f$1_2@dnews...
You might be on to something here Kelly. We upgradded our management server
and clients for Oracle8i and use SQLORA8.DLL (5.2.0.2) as our native DLL32
dll in the BDE driver configuration. This is when the problems started.
Bill Todd (TeamB)
size even though you are not getting a shared memory conflict error. I have
heard of cases where it is necessary to make both changes to resolve the
insufficient memory error although I do not know if it will help in your
case.
--
Bill
(TeamB cannot answer questions received via email)
Kelly
A question still stands, what is the difference between running the application from the exe or from within Delphi (F9)???
Maybe that's a clue the to fix.
* I've tried the bdeadmin fixes, they haven't helped.
Thanks,
Kelly
Dan Rhea
news:3c1f8aa3$1_2@dnews...
Hi Kelly,
I have exactly the same problems when running in the IDE as I do when
running the EXE standalone. The common thread seems to be the BDE 5.1.1
(With a SHAREDMEMSIZE of 57334), Oracle 8 and SQLORA8.DLL. When I run the
same code as an EXE on a Windows 98 system that uses the same BDE (with
default SHAREDMEMSIZE and SHAREDMEMLOCATION settings), Oracle 8 but an older
version of the DLL, I don't have any problems at all.
I have come to suspect that SQLORA8.DLL has some sort of memory/resource
leak.
A couple of other things... Management server is 2.2, the database is 8.0.4.
I wish there was a way to get somebody to take a serious look at this
problem.
wysza
we recently upgraded our client software for oracle to 8i with an odbc driver 8.01.74.00 - this is
when we started getting the errors.
> >
>
from within Delphi (F9)???
The major difference is that when you run your program in Delphi IDE, it initializes all variables
for you (it sets those to null, false, 0, empty strings....) even if you forget to do it in your
code. If you run your program from exe - you are on your own.
> Maybe that's a clue the to fix.
Of course you can check your software for this.... But at the very beginning you didn't specify that
it happens only in one or another environment.
I think you should accept those facts that people already told you:
* if you terminate your program with ctrl+F2 - it won't free some of its resources => memory leaks
=> crash ~ everybody lives with this and you can't "fix" it :-(
* tune some parameters (like SHAREDMEMSIZE etc - i know you already did that) - it will give you
more memory to play with
* check newest sqlora8.dll on borland web site (in bde update section) - they had a problem with it.
Or if this won't help, try to go back to a previous version of this file, when your software behaved
correctly (replace just this one file).
hth
wysza
zlatko
that we experience in last 2 months.
We had 24/7 running system for several years on windows nt 4 sp6
without problems related with Borland sw but with MS nt4.
Because MS nt4 system problems, every 48 hour restart services
to force RPCSS garbage collection, we were forced to upgrade to win2000
Recently (two months ago) we migrated our system to a
win2000 Server and then headache starts with subject message.
(fortunately MS problems were solved)
In last two months we experimented almost every combination
SHAREDMEMLOCATION and SHARDMEMSIZE we could think of.
The best we could achieve was 3-5 days regular operation and then
we are forced to restart our software (all server modules)
Technical conditions:
4 processor PIII / 800 Mhz Server (IBM netfinity 5xxx)
1 GB RAM
90 GB HDD
Software env:
- 5 MIDAS (MIDAS-ADO) out-of-process servers using ADO and MS sql2000
- 1 MIDAS (MIDAS-BDE) out-of-process server using BDE 5.1.1 and oracle 8.1.5
client connected
to oracle 7.3.4. Oracle server is running on separate computer.
- D6E midas.dll (with D5E midas.dll we had some problems so we upgraded)
Problem description:
1. MIDAS-BDE server process is not running - everything is o.k.
2. MIDAS-BDE server process is running - After some time, depending
on load (3-5 days average), we receive error messages in one of the
_MIDAS-ADO_ server process:
^^^^^^^^^
Insufficient memory for this operation.
(several messages in a row, always
at different location in a code).
This messages are followed by:
Access violation at address 4DB105B7 in module midas.dll Write of address
00000000.
Since this specific MIDAS-ADO server process is gateway to other MIDAS-ADO
servers we could not track the situation on other MIDAS processes
(production environment that shouldn't have downtime)
Exploring the situation everything pointed to BDE as a "subject message"
source.
Current BDE settings:
SQLORA8.DLL
OCI.DLL
SHAREDMEMLOCATION: 5B5E
SHAREDMEMSIZE: 16384
differences between old (nt4) and new (w2k) installation
nt4:
BDE: SQLORA32.DLL, ORA73.DLL
SHAREDMEMLOCATION=default (empty - doesn't work on w2k)
oracle: client 7.3.4 (doesn't run on w2k)
w2k:
BDE: SQLORA8.DLL, OCI.DLL SHAREDMEMLOCATION=5B5E SHAREDMEMSIZE=16384
oracle: client 8.1.5
We suspect the conflict between midas.dll and BDE modules that is very
hard (impossible) to track without the source code.
It could be good to try some BDE replacement components to see if the
problem remains.
Unfortunately this requires a lot of hard work just for testing,
since our MIDAS-BDE server is very heavy BDE dataware components
implementation.
The best bet might be "sqldirect" component suite but with evaluation copy
we
achieve nothing (couldn't run in midas server environment)
Any clues-suggestions would be appreciated?
Regards.
Zlatko
Eric Carman
application or related to the database/BDE.
If you haven't already ruled this out with your application, you might want
to try using a good profiling tool like Turbopower's SleuthQA suite to
identify and correct any leaks that might exist.
Another unusual thing that we encountered with our application when
accessing an Oracle database via the BDE was that if you were creating
Queries in code and manualy preparing them, a memory leak would occur and
eventually slow down the entire application until it failed at some point.
Example:
QuerySelData := TQuery.Create(nil);
try
QuerySelData.DatabaseName := Database1.DatabaseName;
QuerySelData.Sql.Add('select * from TestTbl where Key1 = :Key1');
QuerySelData.ParamByName('Key1').DataType := ftString;
QuerySelData.Prepare;
//Loop with processing....
finally
QuerySelData.Free;
end;
Since our App runs with Interbase, Informix and Oracle we opted to do the
following:
if (Database1.DriverName <> 'ORACLE') then
QuerySelData.Prepare;
Like I said, it is a little unusual, but our leaks (associated with this)
went away.
Hope this helps.
Best Regards,
Eric Carman
"zlatko" <Zla...@zms.pan> wrote in message news:3c3f15b4_2@dnews...
zlatko
We have already solved this prepare/unprepare
thing related to oracle 8 client/BDE memory leakage, at the first migration
step nearly two months ago.
To my opinion it is related with BDE 5.1.1/midas (or D6E-midas) pointers to
a shared memory area.
On next Sunday we'll try to upgrade to BDE 5.2 and look for changes
(I suspect there will be any...).
Thanks again.
Regards.
Zlatko
Colin Attwell
> Example:
>
> QuerySelData := TQuery.Create(nil);
> try
> QuerySelData.DatabaseName := Database1.DatabaseName;
> QuerySelData.Sql.Add('select * from TestTbl where Key1 = :Key1');
> QuerySelData.ParamByName('Key1').DataType := ftString;
> QuerySelData.Prepare;
>
> //Loop with processing....
> finally
> QuerySelData.Free;
> end;
Small observation....I don't see your UnPrepare statement, I presume
you left it out for brevity in your example ?
(If you manually Prepare, you must also manually UnPrepare otherwise you
leak)
--
...............................................................
Every man is a damned fool for at least five minutes every day.
Wisdom consists in not exceeding the limit.
Elbert Hubbard, author, editor, printer (1856-1915)
zlatko
Now we'll move our investigations from BDE toward MIDAS/datasnap.
"zlatko" <Zla...@zms.pan> wrote in message news:3c3f374a$1_2@dnews...
Eric Carman
TQuery.Destroy -> TQuery.Disconnect -> TQuery.Unprepare
I seem to recall the leak you mention, but I wonder if that only applied to
earlier versions of Delphi or if there is something about the unprepare call
in the TQuery.Destroy that prevents the resources from being freed?
Curious,
Eric W. Carman
"Colin Attwell" <co...@new.co.za> wrote in message
news:3C3FDE94...@new.co.za...