То, что написал Мастерская Алекса, верно, но позвольте мне объяснить теорию, стоящую за этим:
как вы, вероятно, знаете, когда вы пишете запрос LINQ-to-Entities, вы пишете что-то, что будет выполнено для вашей базы данных. Для того чтобы это было сделано эффективным способом, вместо выборки каждой сущности, проверки ее по заданным критериям, сортировки результата и таких операций, запрос будет переведен в SQL и запущен для вашей базы данных.
Однако тот факт, что любой допустимый C # принят для вашего запроса, не означает, что весь код, который вы можете написать, имеет перевод на SQL. Известные примеры кода без перевода - это запрос, смешивающий доступ к данным и отражение в ваших классах сущностей, или - как и в вашем случае - код с использованием особых типов данных .NET. Такие запросы обычно могут быть выполнены в два этапа, один из которых работает с базой данных, а другой - с объектами в оперативной памяти. Хотя это, вероятно, не будет столь же эффективным и чистым, как вы хотели бы, поскольку лично мне не нравятся хранимые процедуры, я все же нахожу это намного лучше, чем большинство других подходов, которые вы можете использовать, при условии, что ваши ограничения позволяют вам сделать выбор.
Edit:
сценарий действительно может быть легко обработан при выполнении части запроса на БД и части в памяти следующим образом:
Db.Transaction.Include("Lines").Select(t => new bo.Transaction { t.Id, Lines = t.Lines.OrderBy(l => l.RowNo) }).AsEnumerable().Select(t => new bo.Transacton { t.Id, Lines = t.Lines.ToList()});
Вызов AsEnumerable помогает убедиться, что второй Select запускается для набора объектов, уже извлеченных из БД, и, следовательно, больше не возникает проблема перевода ToList в SQL.