[quote]Originally posted by al0:
I dont't want to meddle with your discussion, but cost of intensive memory allocation/deallocation for dynamic buffer managment may (or may not) heavily overweight benwefits from memory saving.

Yours,

Oleksandr [/quote]Hi,

It depends on situation. For example when you only browsing data (and cache data on client application) from many SQL queries, I think the cost should not be such big. Another thing is that now computers are quite fast (CPU and memory), so cost of dynamic alloc/dealloc should not overweight benwefits from memory saving (IMHO ).

And as Jens said it should be an optional parameter (both for read-only and modifiable TOracleDataSet).

Best regards,
Daniel

[quote]Originally posted by Daniel Stoch:

It depends on situation. Another thing is that now computers are quite fast (CPU and memory), so cost of dynamic alloc/dealloc should not overweight benwefits from memory saving (IMHO ).

And as Jens said it should be an optional parameter (both for read-only and modifiable TOracleDataSet).
[/quote]Definitely, it depends, so I have written "it
may (or may not) overweight ...".

Really, memory allocation maintaince is quite time-consumming process (especially if you have a lot of memory chunks) and borland memory manager is not the best (while it is not hte worst as well). And all this stuff are intended to really large sets we (I guess) million of records. So performance degradation may be noticable. BTW, if datasets are really big it is not very wise to fetch the whole dataset to the client. And I can't even imagine browsing of such amount of data. Reporting? May be, but who need a report with handred thousand rows? And filtering (normally) has to be performed on server. So I'm not sure that any programm really need this dynamic memory management for dataset (IMHO much more likely that program that claim the need in this feateru has serious design flaw).

Yours,

Oleksandr

I'm not sure, that you are completly right.

For example. A table has 20 Varchar2-Fields with Length 4000. This means 80000 Bytes for one record.
1000 Records means 80.000.000 Bytes.
And i think 1000 Records is not so much.
We have sometimes tables with some very large fields, which are mostly completly empty.
In such cases there is a lot memory to save which is not used.

Greetings
Jens

[quote]Originally posted by Jens Fudickar:
I'm not sure, that you are completly right.

For example. A table has 20 Varchar2-Fields with Length 4000. This means 80000 Bytes for one record.
1000 Records means 80.000.000 Bytes.
And i think 1000 Records is not so much.
We have sometimes tables with some very large fields, which are mostly completly empty.
In such cases there is a lot memory to save which is not used.

Greetings
Jens [/quote]Possibly, but for such structure I would consider CLOB instead of varchar2. And fetch them on client only on request.

Yours,

Oleksandr

You are principle right with using clobs. But there are some disadvantages of clobs.

And there are old database structures using varchar2. So it's not allways possible. :-)

Greetings
Jens

[quote]Originally posted by Jens Fudickar:
I'm not sure, that you are completly right.

For example. A table has 20 Varchar2-Fields with Length 4000. This means 80000 Bytes for one record.
1000 Records means 80.000.000 Bytes.
And i think 1000 Records is not so much.
We have sometimes tables with some very large fields, which are mostly completly empty.
In such cases there is a lot memory to save which is not used.

Greetings
Jens [/quote]Exactly, this a good example.

Another one: we browse in our application data from many diffrent selects. And all results are cached on client (for reducing unneeded quering of DB). Then if these selects contain data from Varchar2 fields, application can very fast eat 100MB of system memory. And it is not necessary to fetch 1000000 records, 100-1000 per one select is enough to allocate all of system memory.

And I don't agree with you Oleksandr that "IMHO much more likely that program that claim the need in this feateru has serious design flaw).". There are some specific situations when it is necessary.

[quote]Originally posted by Daniel Stoch:
And I don't agree with you Oleksandr that "IMHO much more likely that program that claim the need in this feateru has serious design flaw).". There are some specific situations when it is necessary. [/QB][/quote]You are right that specific situation may exist. But it still more likely that program has design flaw then that situtation is really so specific.
In opposite case situation will be not specific but quite common

Marco,

did you have any new informations on this issue?

Is it possible to realize this only for the readonly datasets? This can be a lot of help for some parts!!

Greetings
Jens

It's on the list of enhancement requests, but I don't have a concrete date.

Maybe you can publish a list with requested enhancements on this site.

This list would contain the requested enhancements and an indication when/if it will be implemented. (or something like that)

Greetings Johan Visser