This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, I was just looking at the output of the query below for lightspeed and comparing it to entity framework, I noticed you guys seem to use the length of the input parameter as opposed to the length of the column as entity framework does. I thought the way entity framework does it you were able to resuse the execution plan where as in lightspeed if I passed in a parameter of length 6 or greater another execution plan would be created. Am I wrong here? What is the reason to use the input parameters length opposed to the column length?
string name = unitOfWork.Members.Where(m => m.FirstName == "XXXXX").First().FirstName;
exec sp_executesql N'SELECT Member.* FROM ( SELECT Member.Id AS [Member.Id], Member.FirstName AS [Member.FirstName], Member.LastName AS [Member.LastName], Member.Password AS [Member.Password], Member.UserName AS [Member.UserName], ROW_NUMBER() OVER(ORDER BY Member.Id) as RowNumber FROM Member WHERE Member.FirstName = @p1 ) Member WHERE RowNumber <= @p0',N'@p0 int,@p1 nvarchar(5)',@p0=1,@p1=N'XXXXX'
And the same in entity framework compiled query
exec sp_executesql N'SELECT [Project1].[FirstName] AS [FirstName] FROM ( SELECT 1 AS X ) AS [SingleRowTable1] LEFT OUTER JOIN (SELECT TOP (1) [Extent1].[FirstName] AS [FirstName] FROM [dbo].[Member] AS [Extent1] WHERE [Extent1].[FirstName] = @p__linq__0 ) AS [Project1] ON 1 = 1',N'@p__linq__0 nvarchar(4000)',@p__linq__0=N'XXXXX'
Thanks
|
|
|
|
|
This behavior is provider specific, but in general we create ADO.NET parameters by name and value which means the DbType and Size parameters will be inferred. In the case of strings this will be set to the length of the string. This will be what is happening in your case. Ill pop an issue on to our backlog to investigate how this could be handled to specify a more explicit type/size when we are dealing with parameters being used against known entity properties but this isnt likely to something we will be changing in the near future.
Jeremy |
|
|
|
