Thanks,
Bill

And, the funny thing about this is that the grid is only displaying just over 2500 items.  I don't think that is much.  Is that a lot of data for a grid to handle?

Bill

The issue you are fighting here is not specific to the BBS and the BO...it has to do with the amount of data being pulled accross the network...not the grid once the data has been retrieved.  2500 records is actually a lot of data when dealing with a disconnected data set.....which is not just specific to SF, but .NET development standards.  A ListView in this wouldn't make any difference anyway because your issue is retrieving the data....and in turn once the data is modified, saving the data.

You may have to start rethinking the way that you do things, especially in regards to coming from old types of technology or data-centric languages such as FoxPro and Access.  We too use grids within our medical application.  We also have times when we have great amounts of data that needs to be addressed...but generally you never need to access all 2500 records at once. 

It sounds as though you may want to start looking into threading on teh retrieval and saving of the data.  The BOs already have a property called DataLayerAccessThreads that is designed specifically for thsi purpose on saves.   However, the retrieval of your data will needs to be taken into acount on your side.  Many times we will use a ThreadManager class to retrieve the data and show a "Retrieving Data" window or message and then populate once the data is retrieved.  There are a lot of ways to approach this particular issue, but when you are dealing with disconnected data....and especially when you are going to have such a limited bandwidth, you have to write responsible queries....the Enterprise Server can aide in squeezing out even better bandwidth in an environment like this (since at present you are talking straight to SQL Server)....regardless, if you are bringing back 2500 records (and the records may need to be modified and updated as well) you are going to be creating a bottleneck within your application.

I hope all of this makes sense, but this is not a BBS or framework issue...rather an application design issue that may need to be addressed in order to improve performance...this is something that all of us have to deal with from time to time (I recently reworked some logic to improve performance for this very same reason).

Thanks a ton for the quick response!  I was hoping you would just say, "Set the wadangle property of the wuzzit."  I can accept that I need to do the limitation work on the design side.  No problem. 

Coming from a web environment, the presentation of the data was a mere few seconds (2500 records).  There was no data sorting and such, though.  The trade offs are now showing up with all of that fancy data manipulation stuff in the grid.  There is power in a winform app, but the bandwidth does present its own limitations.

Are there any examples of the presentation of a fancy wait box when a user does a sort or filter? 

Have a great day!
Bill

Yeah, I understand, but in this environment, the data is generally at the same location as the web servers and so there is more internal bandwidth when retrieving the data.

This is kindof like asking, "How long is a string?"   We have a mechanism within our medical software that shows a form on a thread and allows us to update that form....we also use a ThemedStatusStrip for some of the other stuff (most of the end-users preferred the status strip in many cases).  I wish I had a quick answer here, but this is a more in-depth topic and could go many different ways depending upon the design of your system.  Sorry

Or, how do you draw a blank?  I was going to go the route of the status bar.  That will work...no use messing with threads and dialog boxes and such when it isn't all that necessary.  I can add eye-candy once the functionality is in place.  Thanks for the input!

I like that   I will have to start using that one too