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 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.

• When are you creating a transaction?
• Is it possible for the same code to be called at the same time?
• Are the objects in question specific to a session or the application?
• Are you using shared data tables?
• If you turn off transactions do your issues go away?

These are types of things that you need to be asking yourself.  Only you know your exact code and what you have done at this point.  This code is going to be related to your specific application.  So I would begin to work through these questions.