We have not reproduced your memory leak as we had mentioned in the previous comment on this topic.  In regards to your error posted about saving...I think that at this point you may be a little "gun-shy" as this has not changed in the framework in some type.  You are more than welcome to give me steps to reproduce this, but this hasn't changed, Chan.  As I mentioned in my previous post, we cannot reproduce a memory leak nor is there an issue with the transactional saves.  You may forget that we are not only framework developers, but also use the framework in developing a major medical application.  The version to which you are saying you are receiving an error regarding transactions is pushed out into the field and we use transactions heavily in all of our transaction posting.  So I am VERY confident in this code. I think that you have a cross section of assemblies from different versions or something with your structures or SPROCs that could potentially be cuasing this.  As you well know, StrataFrame is a framework for developers which means that many times when an error occurs it has nothing to do with the framework but something within the environment or code that has been developed.  This is always a balancing act to find out exactly where an issue may be occuring.  If you can provide steps to reproduce this then we will most definitely do so.  Otherwise there is nothing I can do to help.

I appreciate your comments.  We too appreciate you and your business. 

Most definitely.  There is rarely ever a situation where you need to bring back thousands of records.  There is no way for a user to comprehend that many records anyway.  It is always good practice to limit the number of records that are returned.  Not just due to memory, but for user interaction, comphension, and usability.

Grids, in any environment, can be great tools.  But they can also come with a vast amount of overhead.  Also, they are not always the best solution for presenting a user-friendly experience.

In our medical software there are three places that we use grids.  They all have to do with billing and showing transactions associated with an account or billing claims going out.  However, we still limit the number of records that come back.  There is rarely a need to load up tens of thousands (or even hundreds in many cases) unless they are directly related to the task at hand.

Example, we had a patient that had over 6000 transactions (that would translate into about 3000 visits to the doctor or so).  That is CLEARLY not the norm for most environments.  But it was the upper end for sure.  When this was loaded into the grid, we made sure it was optimized for this type of experience.  But this was still too much for the end-user to comprehend.  So we have searches and filters to make the data usable...and limit records as well.  6000 records really isn't that many for a grid on WinForms to handle...but for the web....this would be next to impossible to use.  So we apply a filter or search PRIOR to showing the records while still showing summaries and totals for the full record set.  Make sense?

These are just development techniques that make life better for both the developer as well as the end-user.

We have looked at this from a number of angles.  I am at a loss at this point.  Like you, we have spent a vast amount of time trying to help you on this issue.  This doesn't mean that we are not prepared to continue to help, but we have a large number of users that have web applications developed on SF...including ourselves.  Some of your issues are coming from retrieving vast numbers of records into a grid...this is generally not a recommended approach...web or win forms.  However, that being said, I will take one more look.  But at this point, I do not feel like there is a memory leak.  Another reason for this is that the underlying code to which you are referencing here is also call in non-web code which is highly used in reporting and grids on win forms (or binding natively to .NET in win forms).