We do not have DevExpress 8.2 downloaded and tested this using version 8.1.1.0.  When bringing in all 20,000 records, which is unrealistic, it was very slow but there was not a memory leak.  DevExpress is re-evaluating all rows with each navigation forward.

We reduced the query to the top 200 records for a control to look for any type of memory leak, and we actually noticed the memory being cleaned up and getting smaller.  As expected, the memory grew the first few page navigations, but after about the 5th navigation, the memory consumption reduced and began to keep a more level memory base.

I believe that your issue is one of two things:

1. A possible issue with the DevExpress 8.2 grid not cleaning up after itself.
2. Your application is loading too much data and not cleaning up BOs which could cause a memory bloat before there is ever a chance to clean up.

Finally, the WBBS is entirely different than the WinForms BBS.  The Web BBS does not create a unique BO instance for each row.  There is only ever a single BO instance ever used or created.  So the same issue that existed within the WinForms version is not possible on the web.  After looking over the code, we cannot even see where a potential memory leak may occur.

Hope this helps give some direction.  Thanks.

The screen shot you provided doesn't do me any good.  We have taken the sample that you have provided and NOT had the same results.  You already know that if we are to help you we are going to need some form of reproduction otherwise there is nothing we can do for you.  Please provide a sample that reproduces the issue.  I would strongly suggest that you make sure that you have the most recent build and assemblies loaded that I sent to you the other day.  I never posted the source online, so if you recompiled the source, then you are not running the most recent build.

This has happened to you in the past where you accidentally had the wrong version of the assemblies in your environment.  Using the most recent StrataFrame assemblies, we are not experiencing this using a WBBS and a grid.  However, I will not say that the possibility of what you are experiencing doesn't exist...but without a sample that we can reproduce on our side, there is very little I can do in this type of circumstance.

Yes.  As for the file size, I am unsure why it was smaller other than I might have sent you just that one file in debug mode.  But your assessment is correct.

At no time during these tests did we see any form of a memory leak.  This includes the sample that you sent to us.  If you review the attached video, you will see that the memory never increased but at one point does in fact go back down.  We performed more robust tests that this video shows and setup scenarios where large numbers of postbacks and refreshes were called.  We consistenly saw the memory actually clean up and reduce.

At this point I am uncertain what to tell you other than I do not believe that you are using a build that resolves this issue.  We posted a new build in the last day or so that it may serve you well to install to make sure that you did not run on the incorrect assembly.  I know that this has been an issue in the past.

I hope that this at the very least gives you some direction.  Thanks.

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

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.