LINQ is a query language.

LINQ to SQL is a concrete implementation of the query *SYNTAX*, that translates into SQL statements. It is not a free form expression of SQL statements!

If you're thinking in VFP terms I think you will be very disappointed by LINQ TO SQL because it's NOT a free form SQL engine. What it is is an Object to Sql mapping engine that translates object definitions to SQL statements that get executed and return results back into objects.

That's all fine and good for basic things but there are going to be a fair bit of scenarios that can't be expressed as LINQ queries (one example might be calling a system stored procedure or running a query against a different database). The more complex your queries the more likely it's not going to work through LINQ syntax.

That's not to say that LINQ is useless, but you have to be aware that it has limitations and for any cases that aren't covered you'll have to fallback to using plain ADO.NET and some other way to represent the data. That can be a big problem for application consistency.

LINQ also requires that all data that can be accessed through LINQ has been previously mapped and more importantly keeps getting updated to match the database schema if the schema changes (which in Beta 2 at least is not easy to detect or manage).

LINQ to SQL is very cool in demos but once you get into the actual application of using it you'll quickly realize that it's simply not a 'dynamic query engine' that most people assume it to be. In the end it's still a very high level ORM mapping tool that makes the simple case very easy and the more involved cases potentially impossible.

If you compare that to VFP it's a COMPLETELY different approach to the technology. The two have virtually nothing in common.

+++ Rick ---

>>Walter,
>>
>> ...but it does not make sense to slam LINQ in the face for that.
>>
>>If you think I'm 'slamming LINQ' in the face, then you clearly don't understand what I've said.
>
>Ok. Can you update me ?
>
>>And unless you've actually rolled up your sleeves with either beta for VS08, then odds are high that you don't have a strong handle on the issue, which wouldn't be the first time.
>
>Great, here we go again. It is not about detailed implementation, it is about the underlying thought, which is a more abstract query language on the client side. IOW a local database engine. And I've been the one saying from day 1 of .NET that this is important, so not sure what you're trying to imply here.
>
>>LINQ in general is a great new feature - it allows you to query collections, XML, arrays, etc, using similar syntax. That is the great value of LINQ - that you don't have to write different syntax to query each type of object. And the language capabilities like Lambdas supplement LINQ very nicely. I'm using Beta2 of VS08 for an internal project of mine, and am making heavy use of LINQ and the new language features.
>
>>But I have no plans to use LINQ to SQL. It's a step backwards from stored procedures.
>
>I can imagine that passing SQL (SPT) is more effective as well. However from a transparancy pov it might be a valuable option.
>
>>By the way, last night I spoke at a SQL Server User's Group in the Mid-Atlantic, and afterwards talked with someone who is almost universally viewed as a highly-respected individual from the VFP and SQL Server world, someone who has worked and trained on both sides of the globe. I'm not mentioning the person's name, but suffice it to say that this individual is an even stauncher supporter of stored procedures than I am, and appreciated the fact that my presentation was devoted exclusively to stored procs. And it certainly wasn't much different from other dialog I've had with other folks. So this "narrow, limited" view is a creation in your mind.
>
>Again, anedotecal evidence. I can come up with highly respected oracle DBA who says that both are used but SPs-only are definately less flexible and less common in the implementation they see (and we are talking huge coroporations). See my reply on the topic you started a few months ago. Unless we look at the whole population of installations we are talking about anecdotical evidence without any real life merit. You're living in your SPs world, I'm only using them where they make sense. In applications that need to create SQL on the fly (Query engines), there simply is no other way. Implying otherwise, indeed is 'Narrow minded'.
>
>As I said in my reply back then. It really depends on the project, client and ownership on which implementation makes sense. If you have to build an application upon an existing one owned by the client with sensitive data in there, SP-only might be common as oposed to using SPT. However, if the vendor owns the database and has to deal with ad-hoc queries, then SPT is far more efficient and common.
>
>>Many developpers (including MVPs) just do not have the experience of such data integration and really don't realise the implications of this step.
>>
>>Ah, I forgot....here we go again, you are part of the annointed few, with the shining light of awareness of data-driven apps.
>
>How could you forget.. FYI, I've not a too high opinion of many MVPs on this topic. Most of them where never exposed to applications where high volume data processing was done on anything than a SQL server. Mind you that MVP does not stand for knowledge, but for ones that are awarded for helping others in all variaties of ways. Implying that an MVP title stands for absolute knowledge is beyond me, and in a way is ignorant, arrogant and dumb.
>
>Oh, yeah, since you talked about visionaires and followers.... Can you tell me why
>- We still think that data processing should be done exclusively on one layer: The server ??
>- We still have compile time checking, while it would be much better to have edit time checking as well?
>- We still don't have strict type checking in dynamic type languages as an option?
>- We are able to filter out one record in a database in microseconds, while it takes an hour to search for a file on you HD ?
>
>It is just that change in these areas is like turning an elephant. There is a lot of resistance on established mechanisms and few are able to look beyond that. It also requires quite an investment in developping and maturing those mechanisms. This in a way is happening to .NET.
>
>>(SQL server is not targeted at .NET exclusively).
>>
>>Exclusively? Of course not. But there's an increasingly large point of intersection between the two.
>
>So how could you possibly imply there is a relation between the extensions of T_SQL 08 and .NET -SP ussage ?
>
>BTW, since you did not live up to your promise to answer my email on the topic. What can you do in a SPs you cannot do in dynamic SQL (Send a batch as a script)?? I fail to see the point for SPs here.
>
>Walter,