>We are currently in the process or rewriting our application under .net. We've hired someone with a great deal of knowledge in C# and all the latest OOP design skills. He's very sharp, and the application is coming around nicely. But...some parts of the system are running slow and I'll try to explain.
>
>We are utilizing the CLSA framework, and Persistent Datasets 2.0 (http://www.lastcomponent.com/) for the business layer. Our data for both the old and new is in SQL 2000. For the most part, the new application is currently utilizing the same stored procedures we use in the old vfp application. We have SQL 2000 developers edition installed locally on his machine along with our database.
>He has the old VFP (exe version) running on his workstation also. When the vfp application launches the first time the machine is turned on, there is about a 2 second pause on the first big load of data since SQL doesn't have anything cached. After that it, fast at changing parameters and reloading the data. Now that we have the .net app to that same point, when it runs the first time on the same dataset with the same parameters (even after the vfp.exe has ran) it "times out" on executing the same stored procedure with the same parameters. It does this about 3 times before it finally can return results. After that the system responds just about as fast as the vfp one.
>
>It would seem to me, that since the vfp application had already ran the same stored procedure with the same parameters, the .net version calling the same stored procedure would have returned the results quickly, at least without timing out.
>
>I'm looking for links/articles/suggestions that I can look into. Off the top of my head, it seems that my odbc connection from the VFP application out-performs the .net version. The code is utilizing the SQL Client provider and not the OLDDB provider.
>
>I know this is very broad but I'd appreciate any help or information that someone else might have.

What volume of data are you getting back from the server, # of rows and more importantly is the filed list identical to the csla class needs? That last statement means if your doing a Select distinct * from my tableA left join tableB where yada yada just to fill a dropdown list you may be setting yourself up for problems with CSLA.

I found that I usually generated a specific SP for every CSLA class. If the class is to contain a list then it does so. If the class is to hold child objects am I thinking that I'll just put an entire tables contents into 1000 child objects?

OTTOMH I would guess that your use to having all the data in cursors, and finding that putting the same VOLUME into classes is killing your app.