Entity Framework 3.5 + SQL Server Compact 3.5, медленная производительность из-за литья

Question

Я использую VS2008, .NET 3,5, Entity Framework 3.5, Sql Server Compact 3.5 SP2. Доступ к SQL SC 3.5 осуществляется с помощью EF с использованием первого подхода к базе данных.

Я использую простой запрос (linq и EF), который должен использовать существующий составной индекс для столбцов StanjeId (tinyint) и ArtiklId (int).

var compQuery2 = from art in MobileDb.Artikl 
          where art.Stanje.StanjeId == (byte)1 
          && art.ArtiklId == tmp1 
          select art; 

var quer1 = MobileDb.Artikl.Where(a => a.Stanje.StanjeId == (byte)1 && a.ArtiklId == tmp1); 

Сгенерированный запрос с использованием (compQuery2 as System.Data.Objects.ObjectQuery).ToTraceString() является:

SELECT 
1 AS [C1], 
[Extent1].[ArtiklGuid] AS [ArtiklGuid], 
. 
. 
[Extent1].[StanjeId] AS [StanjeId], 
[Extent1].[ZemljaPorijeklaDrzavaGuid] AS [ZemljaPorijeklaDrzavaGuid] 
FROM [Artikl] AS [Extent1] 
WHERE (1 = (CAST([Extent1].[StanjeId] AS int))) AND ([Extent1].[ArtiklId] = @p__linq__4) 

Проблема заключается в том, что сгенерированный запрос использует приведение в целом в котором части запроса для столбца StanjeId хотя StanjeId имеет типа TINYINT (байты эквивалент). Это заставляет SQL SC 3.5 не использовать поиск индекса, но очень медленное сканирование таблицы (таблица имеет >1M записей).

Как получить EF 3.5, чтобы не использовать CAST as int в той части, где сгенерированный SQL-запрос?

Answer 1

попробуйте этот оператор
Byte.CompareTo(Byte), art.Stanje.StanjeId.CompareTo(one) == 0,
, даже если это явно выполняется, нам нужно будет начать поиск исходного кода для методов diff.