> Now there's a 64-million dollar question. Yesterday it was the server that
> was showing the memory growth. Today it is the client. Still, at least it
> brings you closer to isolating the memory eater.

Sorry if I wasnt clear, but the client and server are on the same machine.

> There are big holes here. We don't see the loop.
>
> Also - is it the case that each XML document potentially loads data into a
> different table?

Yes, the table the data is being loaded into is dependant on the parameters in the xml document.

> If yes, then a costly operation like the above is probably unavoidable, as
> long as it is your design choice to re-use the same object over and
> over. There's too much potential here for a wrong step to cause a leak.
> I'd want to cleanly hard commit the transaction and destroy the DSQL object
> when each XML document is finished with, unless there is some (so far
> invisible) rationale for your approach.

There is only one xml file that all of the data is fetched from, I have already tried doing a hard commit and destroying the dsql at the end of each record, which showed no difference on the client side.

> If no, then this costly operation can't be justified. Create the dsql
> object once, set it up, and keep it prepared until you don't need it any
> more. This too has the potential to cause leaks, which some
> strategically-placed try...finally blocks will go a long way towards
> eliminating.
>
>
>
>>For the majority of the inserts and updates there is only a tiny jump in
>>the memory usage of the client when the dsql is prepared, it is only the
>>large records coming down that cause the huge jump in memory.
>
>
> If the problem looks like a memory leak in your app (a gazillion stream
> objects floating around in VM,? or large string variables doing likewise?)
> then we don't have enough info so far to identify the hotspots.
>
> Inspect closely what you are doing throughout the cycle: where the XML doc
> is coming from (a blob? a COM server? a file?), how you are managing it,
> what you are doing with the doc (streams, substrings, ticker variables,
> etc.), whether you are trying to update the same rows that were inserted
> earlier in the cycle, blah, blah, blah.)
>
> Do you have a resource tracker that you can run over the client app? It
> makes life a lot simpler when memory leaks beep at you...

No, I don't have a resource tracker, I'll have a google for one and try that out, do you have any suggestions (we're using C++ Builder)?

Thanks for the help.

> Helen
>

-Ryan


[Non-text portions of this message have been removed]