>>>>>Thanks again, Rob.
>>>>
>>>>https://www.google.com/#q=entity+framework+top+2
>>>>
>>>>Is there a reason you care about what the type of the parameter is? Is the difference between a varchar(8000) and char(6) as a parameter type causing issues for you?
>>>
>>>Our test database is rather small, so I can not say if it will be causing issues or not on a big database. It is for me just strange to see that declaration of the parameter while the type of the column is correctly specified.
>>>
>>>The OP in the StackOverflow question you pointed out said that there was a performance difference in using correct size for the parameter vs. 4000 for nvarchar parameter.
>>
>>This is probably a case of premature optimization then. If it is causing a performance issue then you may want to look into may want to look into mapping your queries to stored procedures.
>
>I posted an idea in EF web-site. Anyone who wants to vote on it, please add your vote.
>
>https://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/6286842-for-char-nchar-and-varchar-nvarchar-columns-use-th

Not my field and I may be misunderstanding. In the link Rob posted it implies that using cmd.Parameters.AddWithValue will set a fixed length - but at the expense of adding multiple plans for each different string length. Snip:

// produces an nvarchar(7) parameter
cmd.Parameters.AddWithValue(
"SELECT * FROM authors WHERE au_fname = @name", "@name", "Johnson");

I wonder if padding 'Johnson' to the length of the field would be a reasonable compromise ?