Linq to SQL conversion performance

[matt ryan]

I am experiencing an issue with how LinqConnect translates Linq queries to SQL. For example the following code is translated like this.

Code: Select all

from server in context.Server
where server.Name == serverName
select server;

Code: Select all

(@p0 nvarchar(12))SELECT [t1].[name], [t1].[description], [t1].[serverid]
FROM [dbo].[server] [t1]
WHERE [t1].[name] = @p0

The problem is that the serverName parameter is translated to a nvarchar while the column is a varchar which causes the query to perform unnecessary conversions. This stack overflow post demonstrates a method to reactively adjust the DbType of the query's parameters. I have been unable to find a way to pro-actively change these occurrences. Is it possible to influence the translation mechanics to alleviate this?

LinqConnect version 4.1.184.0

[MariiaI]

Thank you for the report. We have reproduced this issue. We will investigate it and inform you about the results as soon as possible.

[matt ryan]

Do you have a status update for this issue?

[MariiaI]

The bug with the discrepancy of the parameter's type and the column's type in operations of equality (==) and inequality (!=) for varchar/nvarchar data types is fixed.

Try the new build of LinqConnect 4.2.338!
It can be downloaded from http://www.devart.com/linqconnect/download.html (trial version) or from Registered Users' Area (for users with active subscription only).
For more information, please refer to http://forums.devart.com/viewtopic.php?f=31&t=27983.

[matt ryan]

This version seems to have resolved the issue. I will update if we discover any additional problems.

Thanks