Hi!

I wanna ask something about memory tables, because I don't understand them fully.
I created a test application to modelling.

The application, that do this:

procedure TForm1.BitBtn1Click(Sender: TObject);
begin
 OpenDB;
 with qm do begin
   Close;
   SQL.Text := 'select * into memory XAXX from work; select * from memory XAXX';
   Open;
 end;
end;

This "work" table have 3 files, IDX, DAT, BLB, and total size (with all) is: 10,8 MB (4,1
+ 5,1 + 1,4).

When I opened this application, the server created three files in the server, but they
have only 1k - 50k size.
The memory usage of the dbserver growed with 10MB.
Because of fake file size, I checked the disk usage with "dir", and I saw that different
between prior (non connected), a connected state is 438K.

Hmmm... It seems to be the server held the data in it's memory area (RAM, VM), not in the
filesystem!

After that I started this app, and I closed it again, and again.
Everytime I saw the temp table creation (1k-50k), and the disk usage growed, and after I
closed the app, it normalized to prior state.

But the server's memory usage is not! It is growing with 10 MB for each app running, and
it is not decreased!
I started this app 8 times, and I got 80 MB memory usage by the server.

So I wanna ask: when this memory will released by server?

Why it held? Why not the filesystem used? Or it will flushed to files later?

Please help me to clear the definition of the memory tables, and to I can get solution our
OM error (possible caused by memory tables).

Thanks for it:
  dd

Durumdara

>    SQL.Text := 'select * into memory XAXX from work; select * from memory
> XAXX';
>    Open;
>  end;
> end;
>
> This "work" table have 3 files, IDX, DAT, BLB, and total size (with all)
> is: 10,8 MB (4,1
> + 5,1 + 1,4).
>
> When I opened this application, the server created three files in the
> server, but they
> have only 1k - 50k size.
> The memory usage of the dbserver growed with 10MB.
> Because of fake file size, I checked the disk usage with "dir", and I saw
> that different
> between prior (non connected), a connected state is 438K.
>
> Hmmm... It seems to be the server held the data in it's memory area (RAM,
> VM), not in the
> filesystem!
Yes, as you said before *memory* tables. Memory tables are held in server
memory (RAM)

> After that I started this app, and I closed it again, and again.
> Everytime I saw the temp table creation (1k-50k), and the disk usage
> growed, and after I
> closed the app, it normalized to prior state.
It is correct too. You create the memory table and then you have to destroy
it.

> But the server's memory usage is not! It is growing with 10 MB for each
> app running, and
> it is not decreased!
Just add the following code in the form destroy of you application.

Sql.Text := 'drop table if exists memory\xaxx';
ExecSql;

Eduardo

"Eduardo [HPro]" <contato@hpro.com.br> wrote:

Durumdara

>> Hmmm... It seems to be the server held the data in it's memory area (RAM,
>> VM), not in the
>> filesystem!
>Yes, as you said before *memory* tables. Memory tables are held in server
>memory (RAM)

It is ok, but sometimes they are flushed to disk. I saw many times, but I don't understand
why sometimes yes, and why sometimes not??!!

>> But the server's memory usage is not! It is growing with 10 MB for each
>> app running, and
>> it is not decreased!
>Just add the following code in the form destroy of you application.
>Sql.Text := 'drop table if exists memory\xaxx';
>ExecSql;

OK, I know it, but
a.)
This is not my code, and I must follow, and correct all usage of these tables, one by one
(60-100?). Very hard area for me.
b.)
I don't understand, that the memory usage of the dbserver why not decreased.
For example: in 12:00 I started 10 pieces of the memory eater. Each of them eating 10 MB
of server memory with "select * from XAXX".
The temp. files are closed, and it is 15:00, but the server memory usage constantly 100 MB.
Dead session count = 0; Intervals = 300; DS Cleanup: 30 sec.

So what is it that held the memory?
And when it will released?

Thanks for your help:
 dd

Hi!

Next test: I can realize the Out of Memory error, when I used a code to "select into
memory X", and don't delete the results.
Interesting, that memory usage does not decreased, the dbserver held all memory that it
can, and never release the older client's non-deleted memory tables...

Hmmm... I thought before that the server reuse the memory of the disconnected sessions,
but it seems that isn't do it.

Why???

Thanks: dd

<< Next test: I can realize the Out of Memory error, when I used a code to
"select into memory X", and don't delete the results. Interesting, that
memory usage does not decreased, the dbserver held all memory that it can,
and never release the older client's non-deleted memory tables... >>

See my other message regarding this method:

http://www.elevatesoft.com/manual?action=mancompmethod&id=dbisam4&product=d&version=7&comp=TDBISAMSession&method=RemoveAllRemoteMemoryTables

Just add this method call to your remote session in the client application
before you close the application, and that should take care of the problem.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:26B9C87A-0DFB-4D23-92E4-2EFA4F638FA8@news.elevatesoft.com...
>
> See my other message regarding this method:
>
> http://www.elevatesoft.com/manual?action=mancompmethod&id=dbisam4&product=d&version=7&comp=TDBISAMSession&method=RemoveAllRemoteMemoryTables
>
> Just add this method call to your remote session in the client application
> before you close the application, and that should take care of the
> problem.
>

This applies also to V4?

Robert

Robert,

<< This applies also to V4? >>

Shoot, I forgot that he was using 3.x.  This actually *only* applies to 4.x,
and not 3.x.  He's going to have to make sure to drop all memory tables
manually after he is done using them.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
>Robert,
<< This applies also to V4? >>
>Shoot, I forgot that he was using 3.x.  This actually *only* applies to 4.x,
>and not 3.x.  He's going to have to make sure to drop all memory tables
>manually after he is done using them.

Thanks. I found this way, but I inspected this problematic corp, and I saw that they are
not close the application until 16.00 (the ending of the work). So all things are existing
continously.

This is the time to I find some way to recompile this version of the DBISAM server.

I wanna ask that IF WE DON'T BOUGHT THE SOURCE FOR THIS VERSION FORMERLY, CAN WE BUY IT NOW?

The 4.x version is problematic because many thing changed, and we need to recode all
specific things in all source.
This is hard and that can be the source of many new bugs.

So I wanna ask that:
a.) Can we buy 3.x sources from you?
b.) Can we compile with Delphi 6.0 Prof/XP?
c.) Can we build it with FASTMM (version problems?)?

Thanks for your help:
 dd

<< a.) Can we buy 3.x sources from you? >>

Contact Sales at sales@elevatesoft.com and they will help you with this.

<< b.) Can we compile with Delphi 6.0 Prof/XP? >>

Yes.

<< c.) Can we build it with FASTMM (version problems?)? >>

Yes.

--
Tim Young
Elevate Software
www.elevatesoft.com