>>I assume you mean Visual FoxPro. I can only consider C# solutions. In fact, my company is switching from VFP to C# largely to address performance problems between VFP and MS SQL 2000. I assume that there is a optimal method in C#.
>
>This is NOT about languages, but about how/where to process the data.

Sorry for misunderstanding you. I am still a novice programmer. Ideally, I would think that processing the report nearby, on a fairly powerful machine, would be ideal, using a tool made for major data crunching. That appears to be a common idea among all the people who took the time to respond. Unfortunately, because the report is only done occasionally, budgetary constrainsts make buying additional tool impossible. We have been charged with finding the best solution using our current system in .NET. We are trying to eliminate VFP. Not knowing VFP, I don't know all the reasons, so I just accept it as a constraint.

>The paradigma of [ado].net is to work on rather small sets in [client] memory. Yours is one of tasks where working on the client disk seems best: the workload is offloaded from the server and the amount of data seems to be to large for memory processing, forcing swaps [first assumption on the reason of slowness, should be verified. Second assumption: running the report preparation on the server is ill advised, because it either blocks other requests or takes too long - also to be verified in advance, but based on your description<g>].

Both of these assumptions are correct.
>
>Feeding the data into a local instance of MSDE/SQL server would be a c# solution, as would be a solution using any another "local data handling package" for .net. Please google for yourself - besides vistaDB and codebase [I haven't used both] there are quite a few others. I guess deployment needs/licening and dev training cost would be the most influential parameters to check.

Would this mean installing MSDE separately on the machine and accessing it as a service from C# or can you bundle the MSDE engine into a .NET project installer? I didn't have much luck finding samples for accessing MSDE from C#. Is it just another connection string like any other database, only local? Is it possible to query data off the main DB server directly into MSDE or must .NET download it then upload it into MSDE?

>It is exactly the area where Visual FoxPro works best and calling a vfp COM object in a .net solution for this special case might even be the most cost effective solution because some vfp developer knowledge exists at your place. But the other alternatives should be not far behind in performance, if it gets "political". If running those reports on handhelds is deemed necessary, you also have a technical reason *and* technical filtering criteria for local data handling packages<g>. If you decide to work with such a package, pls. keep me informed on the packages evaluated, choosen and on your impression after some expirience. On the other hand: 300000 records should keep you well below MSDE's 2 gig barrier, and processing speed of MSDE and SQL server is identical (on the same machine), if there is only one concurrent query set running. If you have to run the report only on one workstation, either install MSDE or one of the cheaper SQL server licenses. If you have to run the report on
>many workstations, I'ld lean because of security and install issues to a dedicated package [including vfp <g>].

We haven't decided if the report will be run on one client machine, a small group of client machines, or remotely on a session server near the database. It is unlikely we will be buying any packages, but MSDE seems like it is worth considering. Assuming MSDE is a service, can you start the service via C# code, use existing tables in one of its databases, and then quit the service again?

Danke for your patience with me.
>
>my 0.02 EUR
>
>thomas