geocoins-software
asked on
query-related memory leak
Any help or info would be appreciated...
I have worked hard to isloate a simple example
of query-related memory leak (cause is unknown).
When running against sql server 2005,and a query is opened, closed and freed, In many cases, the memory used by the dataset is not recovered.
We track private bytes using the performance moniter, But even the crude task moniter shows that the machine will soon lockup as memory is held (and it does).
The code below shows two different select statements. One does not cause a problem, the other does.
The statements and tables are unremarkable and quite similar.
Hmmm? (it just does create-open-free, over and over)
We use corelabs driver 3.10.8.0
We use Delphi 7 and the standard Luxena access components
This effect is not being seen with Interbase or Oracle
only against MS sql Server
var
q: txquery;
s: string;
begin
WHILE TRUE DO
BEGIN
q:=txquery.create(nil);
try
q.sqlconnection:=gm_vcontr ol;
// q.sql.add('select id from events'); //no problem - and most tables
are ok
q.sql.add('select id from cc_late_interest '); //significant memory
loss
q.open;
while not q.eof do
begin
s:=q.fieldbyname('id').ass tring;
q.next;
end;
finally
q.free;
end;
END;
end;
below is the strucure of the tables
CREATE TABLE EVENTS
(
ID INTEGER NOT NULL,
EVENT_TYPE INTEGER DEFAULT 0,
EVENT_INFO VARCHAR(1024),
EVENT_DATETIME DATETIME,
USER_ID VARCHAR(14),
SERVER_ID INTEGER DEFAULT 0,
BUSINESS_DATE DATETIME,
EXPLANATION VARCHAR(1024) DEFAULT '',
PRIMARY KEY (ID)
);
CREATE TABLE CC_LATE_INTEREST
(
ID INTEGER NOT NULL,
STATE VARCHAR(2) DEFAULT '',
STATE_TITLE VARCHAR(40) DEFAULT '',
PID VARCHAR(3) DEFAULT '',
PID_TITLE VARCHAR(40) DEFAULT '',
RATE NUMERIC(14, 2) DEFAULT 0,
AFTER_DAYS INTEGER DEFAULT 0,
TO_DAYS INTEGER DEFAULT 0,
RECIP_TYPE VARCHAR(1) DEFAULT '',
CLAIM_INPUT_TYPE INTEGER DEFAULT 0,
DAYS_TYPE INTEGER DEFAULT 0,
MINIMUM NUMERIC(14, 2) DEFAULT 0,
MINIMUM_RECIPIENT_TAG INTEGER DEFAULT 0,
CALCULATION_TYPE INTEGER DEFAULT 0,
RATE_TYPE INTEGER DEFAULT 0,
PRIMARY KEY (ID)
);
I have worked hard to isloate a simple example
of query-related memory leak (cause is unknown).
When running against sql server 2005,and a query is opened, closed and freed, In many cases, the memory used by the dataset is not recovered.
We track private bytes using the performance moniter, But even the crude task moniter shows that the machine will soon lockup as memory is held (and it does).
The code below shows two different select statements. One does not cause a problem, the other does.
The statements and tables are unremarkable and quite similar.
Hmmm? (it just does create-open-free, over and over)
We use corelabs driver 3.10.8.0
We use Delphi 7 and the standard Luxena access components
This effect is not being seen with Interbase or Oracle
only against MS sql Server
var
q: txquery;
s: string;
begin
WHILE TRUE DO
BEGIN
q:=txquery.create(nil);
try
q.sqlconnection:=gm_vcontr
// q.sql.add('select id from events'); //no problem - and most tables
are ok
q.sql.add('select id from cc_late_interest '); //significant memory
loss
q.open;
while not q.eof do
begin
s:=q.fieldbyname('id').ass
q.next;
end;
finally
q.free;
end;
END;
end;
below is the strucure of the tables
CREATE TABLE EVENTS
(
ID INTEGER NOT NULL,
EVENT_TYPE INTEGER DEFAULT 0,
EVENT_INFO VARCHAR(1024),
EVENT_DATETIME DATETIME,
USER_ID VARCHAR(14),
SERVER_ID INTEGER DEFAULT 0,
BUSINESS_DATE DATETIME,
EXPLANATION VARCHAR(1024) DEFAULT '',
PRIMARY KEY (ID)
);
CREATE TABLE CC_LATE_INTEREST
(
ID INTEGER NOT NULL,
STATE VARCHAR(2) DEFAULT '',
STATE_TITLE VARCHAR(40) DEFAULT '',
PID VARCHAR(3) DEFAULT '',
PID_TITLE VARCHAR(40) DEFAULT '',
RATE NUMERIC(14, 2) DEFAULT 0,
AFTER_DAYS INTEGER DEFAULT 0,
TO_DAYS INTEGER DEFAULT 0,
RECIP_TYPE VARCHAR(1) DEFAULT '',
CLAIM_INPUT_TYPE INTEGER DEFAULT 0,
DAYS_TYPE INTEGER DEFAULT 0,
MINIMUM NUMERIC(14, 2) DEFAULT 0,
MINIMUM_RECIPIENT_TAG INTEGER DEFAULT 0,
CALCULATION_TYPE INTEGER DEFAULT 0,
RATE_TYPE INTEGER DEFAULT 0,
PRIMARY KEY (ID)
);
ASKER
Tried them all
what did it give you?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
developmentguru:
WOW, I didn't think of that. Thanks, I will give that a try and get back to you
WOW, I didn't think of that. Thanks, I will give that a try and get back to you
If you use either fastmm (http://sourceforge.net/projects/fastmm/?abmode=1) or the eurekalog trial (www.eurekalog.com), you might get an extra clue where the memory leaks.