In our application I get a "Out of memory"-Exception in the TRecordDataList.AllocateBlock-Methode when calling GetMem.

This problems doesn't appear when replacing the default-memorymanager with FastMM (http://sourceforge.net/projects/fastmm/).

The problem is also invisible when doing the same work with one of our other supported databases (Our application support 4 DBM's).

So it seems that the default-Delphi-Memory-Manager gets a fragmentation-problem with DOA. The memory-consumption when checking it in Windows-Taskmanager show that the application have only 350 MB of Memory allocated.

Are there any known issues for this problem?

How large are these result sets? Note that for some dataset functionality it may be appropriate to set UniDirectional to True to prevent memory overhead.

Normaly only 1 Record. In some cases up to a few hunderts.

Is there any update on this issue ?
I have a similar problem in a three-tier app. In my case it occurs on opening client datasets. The problem is not isolated to any particular one and the datasets in question can have been previously opened many many times. Also, the problem does not occur with a BDE server layer, only with DOA components.

Beyond the UniDirectional tip, I have no other tips. You can use this in a server application as well if TDataSetProvider.ResolveToDataSet = False.

Yeah - I tried the Unidirectional but it didn't do any good. I wrote a multi-threaded stress test program to constantly open and close a set of datasets - which is TOracleDataSet and TOracleProvider pairs in a multi-threaded server application. This essentially mimics multiple client PCs running against the server layer. Eventually I managed to get Delphi to break while running the server program through the IDE. It failed with an exception somewhere within the TOracleDataSet.InternalInitFieldDefs. I haven't managed to tie it down further than that, as it takes hours, or even days to get it even this far. Does this lead you to think in any specific direction ? This is Delphi 4 by the way, and DOA 4.0.6. This is a production environment, so its a particularly serious problem for my business. Any help or suggestions your have would be gratefully received. Thanks.

Actually, as an addition to the last post, an "out of memory" also occurs in the GetMem call of the OracleData unit TRecordDataList.AllocateBlock.

[quote]Yeah - I tried the Unidirectional but it didn't do any good.[/quote]Why not?

In other words, I get the errors with or without it. So setting Unidirectional had no effect.

That's odd, because with UniDirectional there is no memory overhead. Perhaps there are some other memory consuming functions occurring?

Hi Marco. Since my last post I have coded a stress test project to work in a two tier mode, simply opening and closing TOracleDataSet's directly without any three-tier stuff involved, and that works fine. The problem seems to have all the hallmarks of a memory leak type problem, buried somewhere in the provider.pas, or in some unit that it uses. I have tried to use codeSlueth to check for memory problem, but its not my forte and I didn't get very far. It doesn't seem to be in anything my code is doing, because in the stress test project it doesn't really run any code, its just opening and closing client datasets in a pile of threads. There's no processing of the results. If I was able to get a scaled down version of very simple server and client apps, would you be able to have a look at it for me and see if you can spot anything ?
Thanks.

I can check it out with TurboPower Sleuth. Did you use that too?

I am not familiar with that tool. I went looking for it, but I don't know where to get it any more. It looks like its been defunct a while. The turbopower.com website doesn't respond either. Anyway, I have now built a scaled down very of two apps, one for the server layer and another for the client. I have removed any dependencies to any of my own or third party components, apart from DOA obviously, and the query that it runs is off one of the Oracle system tables, so I have removed any dependency on my own database and schema too. How can I send you these ?

You can send it to marco.kalter@allroundautomations.com.

Hiya Marco. Any news ?

Sorry for the delay, I have not yet been able to check it out. I will get to this shortly though, and will get back to you.

Just for further info, I have now written the same test project that I gave you in Delphi 5, and it does NOT seem to experience the same problems. This would seem to imply that its an actual Delphi 4 bug that was somehow fixed in 5. Now sure if that helps you any. It doesn't help me too much because of the size of my applications. I can't quickly convert and release a D5 version. Ta.