>Hi kevin,
>
>>>Again, it depends on what you're doing. If you do not use VFPs datamunging capabilities much and only develop quite straightforward applications, then you should not have much trouble in rewriting the stuff in .NET. However, if you write very complex applications with lots of datamunging (data driven applications) then you're in real trouble with .NET because performance will likely downright suck.
>>
>>I would have to say that the statement above totally sums up why I may not see a problem with some of the performance hits, and you do.
>
>>If I was using .Net+SQL Server for a data-intensive app then SQL Server SP's would be doing the data-crunching, not .Net, making it redundent in that scenario.
>
>T-SQL has only limited capabilities to do this though this but this is going to be improved in the next release (Yukon) where .NET code can be integrated into SQL server.
>
>However, SQL server is not meant to do this task. Actually I would not burden the server with too many of these tasks. The server should do what it is build for: handling raw data. I find using SPs for munging data a misuse of a database server. You're wasting valuable resource in terms of CPU and memory for tasks that can be handled more efficiently on the client.

Um, as far as I understood it thin-client solutions were the intention when using back-end DB's, the idea was that the Server would undertake the heavy datamunging because

A Server that the DB runs on will be at least twice as powerful as an average client PC, not only that but would be "built" as a server, to do what a server does best

If heavy processing was to take a few minutes or more it would be able to run on the server, thus not hogging the client PC and holding up the end user's PC

Due to the lack of a data-engine in other MS app dev tools SQL Server came with the capabilities that lacked in other tools - that indicates to me that SQL Server "was" designed with this in mind

>Of course the trend has been that the SQL server is loaded with more and more of these unintended tasks just because the programming languages like VB and .NET are not capable of doing offline data processing efficiently. In my eyes MS makes the wrong move in making the SQL server more of an application server in stead of providing the developer with tools that are capable of post processing data where it is done best: At the client. If lets say 20 clients are connected to the database 20 desktops CPUs do have a lot more power than one to four server CPUs at the SQL server, not to talk about memory and HD space.
>
>There is so much to gain in processing as much as you can on the client and use the SQL server for only the basic tasks, handling the raw data, maintaining security and integrity. This also makes you application more portable to lets say oracle. It is just a pitty that there are not many vendors (though there are a few), do recognize this fact.

I'm struggling to find a reason why you require so much datamunging in the front-end, it sounds to me that this is the result of the design of the application - and could suitably be re-worked in another dev tool, differently, to avoid all the client-side datamunging.

Kev