Bang on Craig. Single does a SELECT TOP (2) when it generates the SQL.
On 9 August 2010 14:53, Craig van Nieuwkerk <[email protected]> wrote: > Single() shouldn't have to find all results, it just has to check if > there is more than one. > > On Mon, Aug 9, 2010 at 2:49 PM, Michael Minutillo > <[email protected]> wrote: >> First should be quicker than Single shouldn't it? First just has to find one >> result. Single has to find all results and ensure there is only one. >> >> >> Michael M. Minutillo >> Indiscriminate Information Sponge >> Blog: http://wolfbyte-net.blogspot.com >> >> >> On Mon, Aug 9, 2010 at 12:10 PM, <[email protected]> wrote: >>> >>> Yea but you could always use First, right? Single would only be >>> fractionally faster, if at all, >>> methinks.. >>> >>> >>> On Mon, Aug 9th, 2010 at 1:30 PM, Michael Lyons <[email protected]> >>> wrote: >>> >>> > I totally agree with you Tony. I've always felt the LINQ to SQL designer >>> > was >>> > somewhat more thought out and aimed at the whole KISS principle, while >>> > LINQ >>> > to Entities tried to be "enterprisey" when it really didn't need to be. >>> > >>> > Admittedly I haven't taken a look at EF since back when it first came >>> > out, >>> > with my biggest turn off being Single() / SingleOrDefault() missing. Has >>> > this been added now? >>> > >>> > ------------- >>> > Michael Lyons >>> > >>> > >>> > -----Original Message----- >>> > From: [email protected] >>> > [mailto:[email protected]] >>> > On Behalf Of [email protected] >>> > Sent: Monday, 9 August 2010 12:19 PM >>> > To: [email protected] >>> > Subject: I don't like Linq to Entities >>> > >>> > Hi all, >>> > >>> > I have my archidev hat on at the moment (given my last few emails I'm >>> > betting that doesn't >>> > surprise people) >>> > >>> > One task I have been looking at is figuring out how to convert our >>> > applications from Linq to SQL >>> > over to Linq to Entities. The reasons are that Linq to Entities is >>> > installed >>> > out-of-the-box, and Linq to >>> > SQL has to be added in (this implies a preference by Microsoft), LINQ to >>> > SQL >>> > is no longer receiving >>> > support from Microsoft, and LINQ to Entities supports multiple databases >>> > and >>> > devices. >>> > >>> > Apart from that, it provides much of the same; everything that Linq to >>> > SQL >>> > does, Linq to Entities >>> > can certainly do. But Linq to Entities gives me no other real advantages >>> > within my environment >>> > other than "architectural correctness" perhaps. >>> > >>> > But LINQ to SQL has one distinct advantage over Linq to Entities. >>> > >>> > This is the major major gripe that I have, and on this basis is enough >>> > for >>> > me to choose SQL over >>> > Entities. >>> > >>> > When I drag a stored procedure from the server explorer onto my linq to >>> > sql >>> > designer, the stored >>> > proc appears in the designer in a column on the right. If I have other >>> > objects on the designer, such >>> > as a table/entity, I can map the stored proc output to that object. It's >>> > all >>> > visual and I can see >>> > whether everthing has been done right. It's also simple for my >>> > developers >>> > to >>> > see whether they've >>> > provided everything they're meant to provide when returning data from >>> > the >>> > database. >>> > >>> > In the LINQ to Entities case, I drag a stored proc onto the designer. It >>> > _disappears_ into the ether. >>> > Yes, it was added, but there's nothing visual on the designer to tell me >>> > that. Not only that, but I >>> > have to _map_ the stored proc to a function by using a right-click >>> > context >>> > menu and performing a >>> > function import. After the function import, the routine is available to >>> > be >>> > called, but it still does not >>> > appear on the designer. I have to open the Model Browser to find my >>> > stored >>> > proc, and that's on a >>> > tab behind my solution explorer. >>> > >>> > So that, and that alone, is enough to make me reject LINQ to Entities. >>> > It >>> > is >>> > the pain of extra >>> > administration. And it shouldn't be that hard for the designer to be >>> > fixed >>> > to behave in a similar >>> > fashion to LINQ to SQL as well. There is nothing that says that it would >>> > be >>> > impossible for a stored >>> > procedure to be dragged onto the canvas and have the function imported >>> > immediately based on >>> > the stored procedure name, and have the stored procedure itself >>> > available >>> > via the properties of >>> > that function. >>> > >>> > So that's my gripe. >>> > >>> > Regards, >>> > Tony >>> > >>> > >>> > >>> >>> >>> >> >> >
