Send me a sample database and application demonstrating this and I will try
and see what I can come up with. There is something fishy for sure since I
use TIB_Cursor all the time, as do many others, and there isn't such a
problem.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Dennis McFall" <dmcfall@...>
To: <IBObjects@yahoogroups.com>
Sent: Saturday, August 10, 2002 10:47 AM
Subject: Re: [IBO] Memory leak persists


>
> > A persistent IB_Cursor, properly managed, will be much
> >more efficient (cause less fragmentation of memory) than this repeated
> >thrashing.
> >
> >Create the persistent IB_Cursor object in the IDE with the following
> >properties:
> >
> >IB_Connection: ModOne.Connection1
> >IB_Transaction: DModOne.Transaction1
> >SQL:
> >SELECT LASTNAME, FIRSTNAME FROM PERSONS
> >WHERE NAME_OID < 120000 file://Helen: I even removed the parameter and
the
> >ORDER BY
>
>
> The Delphi code is listed below the MemUsage listing. The MemUsage is
still
> staying an additional 9-10 MB higher after each click of StringTest (each
> of which is followed by a click of btnClearList, which frees about 288 KB,
> which is predictable for about 5000 strings of about 40 char each).
curTest
> is a TIB_Cursor component on frmMain, whose IB_Transaction and
> IB_Connection properties are Connection1 and Transaction1, which are other
> components on frmMain. AutoFetchAll is false.
>
> Transaction1:
> Autocommit : False
> Isolation: tiCommitted
> LockWait: True
> ReadOnly: False
> RecVersion: True
> Server Autocommit: False
>
> The SQL property of curTest is 'SELECT FIRSTNAME, LASTNAME FROM PERSONS
> WHERE NAME_OID < B120000'; No parameters, no ORDER BY.
>
> MemUsage after series of clicks on btnStringTest/btnClearList :
>
> Base on application startup: 11016
> after btnStringTestClick #1: MU = 22752
> after btnListFreeClick: MU = 22468 (284KB freed when aList is free'd)
>
> after btnStringTestClick #2: MU = 33056
> after btnListFreeClick: MU = 32784 (288 KB freed)
>
> after btnStringTestClick #3: MU = 42520
> after btnListFreeClick: MU = 42296 (224 KB freed)
>
> after btnStringTestClick #4: MU = 52104
> after btnListFreeClick: MU = 51816 (288 KB freed)
>
> So after 3 additional calls (in the handler for btnStringTestClick) to
> curTest.First, Close, and Unprepare, the MemUsage is 29.3 MB more than it
> was after the first call. This pattern continues until the machine slows
to
> a crawl.
>
> procedure TfrmMain.btnStringTestClick(Sender: TObject);
> begin
> aList := TStringList.create;
> with curTest do try
> if not prepared then prepare;
> First;
> if not eof then while not eof do begin
> aList.Add(Fields[0].AsString + ' ' + Fields[1].AsString);
> Next;
> end;
> finally
> Close;
> Unprepare;
> Transaction1.Commit;
> end;
> end;
>
> procedure TfrmMain.btnClearListClick(Sender: TObject);
> var i:integer;
> begin
> aList.Clear;
> aList.Free;
> end;
>
>
> Greatly perplexed and needing a solution.
>
> Dennis McFall