Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The clean way is to state the fields you actually want in expression, put them in your mid-tier objects and then use any auxiliary functions to modify them latter.</p> <p>I'm not sure if you realize that a class representing SQL table for LINQ is a DTO class - it defines the grammar used by LINQ-SQL translator. Injecting a property into a DTO which is not mapped to the SQL table is not even supported - meaning that translator can fire at will. Attributes define the grammar and anything not defined by them doesn't exist for expression translator.</p> <p>Entities named in the from clause are not objects - they are just symbols used to help spelling out actual table fields that will be fetched. A field not named explicitly in select is a field not fetched - at least that's the goal of the translator, it may have to let a few slip through. For example if that ent.FormattedName is not declared, that's a slip and can explode latter.</p> <p>So, that FormattedNumber property injected into DTO class doesn't even exist in the grammar. It's not a "calculated field" - that term is strictly for SQL table definitions and if you had one it would be in DTO's grammar. Notice that error said very precisely "local expression" - very limited scope. </p> <p>You could try to cheat it by a nested lambda expression invoking a static function on the whole "tel" which might triger fetching of the whole record - or throwing another exception.</p> <p>Other LINQ-s, which are not translators, can have relaxed rules. LINQ-SQL has to be either very strict or very slow and it's already slow enough :-)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload