>>>Nonetheless, it is a method to get a row set. I conceded it was not like full-blown SQL - but in the end, does it matter? All of this work should be taken care of on the server anyway....
>>
>>John,
>>
>>Let me begin by stating a few facts about my job and my employer.
>>
>>I work for the Shaw Contract Group. We’re a part of the Shaw Industries Group. Shaw used to be a publicly traded (NYSE), Fortune 500 company, however, a couple of years ago we were acquired by Berkshire-Hathaway. Shaw was and is the largest manufacturer of floor covering in the world. The Contract Group provides carpet, both broadloom and tile, for offices, hotels, airports, restaurants and so on. In fact, I would be surprised if we didn’t manufacture some of the carpet used in the Microsoft campus in Redmond.
>>
>>The point of this is that this isn’t a “Mom and Pop” organization. To the contrary, it is a world-class company.
>>
>>My role in this is to provide financial information used on both ends of the spectrum: How much will it cost? And how well are we doing? By this I mean my work determines the cost of a product and my work determines not only how well we did in terms of our margin.
>>
>>In the latter case, we have what are referred to as “Efficiency Reports”. These reports tell the Financial Systems managers how we performed for the various processes involved in the manufacture of carpet. There are about 14 different processes, although some referred to as “Continuous Processes”, share the same application. One process, tufting, has approximately 30 different reports, using different groupings.
>>
>>We’re in the process of moving these applications from Fox tables to SQL Server. This brings me my question.
>>
>>Can you give me a case where, under these circumstances, it would be more cost effective to use a completely use a .NET solution rather than including Fox in it? To my way of thinking, with Fox, I can create one query to properly generate these reports against a data set from SQL Server. If, however, I go with a completely .NET solution, I have to create 30 different stored procedures (unless, of course, I set the compatibility level at 6.5 for the database, which is a bad idea.) and have 60 trips back and forth over the line, not to mention the maintenance of them. Using Fox, I can reduce this to two trips and have one query to support.
>
>Hi George,
>
>You might be able to do it with a lot fewer than 30 SPs. SPs can accept parameters, you can use string functions to build dynamic strings/statements that can be EXECUTEd on the fly, etc. You may already be using some of these techniques in Fox.
>
>My impression of T-SQL (based on limited experience) is that it's primitive compared to Fox, but the essential features seem to be there and you have access to the SQL engine of SQL Server, which is more complete and powerful than VFP's.
>
>As for more cost-effective - maybe it can never be, considering that you've already done it in Fox - why spend new money re-inventing the wheel in SQL Server? If it's complex, you're the only one who can judge that.

Al,

The problem isn't just the possibilities of 30 sps. The problem is also the number of trips over the line. IOW, it doesn't scale as well as querying a Fox result set. Granted it can be done without the 30 stored procedures, but a what cost in terms of server load?