10

J'utilise la recherche de texte intégral avec LINQ dans mon application et comme cela n'est pas pris en charge par LINQ, j'utilise une solution de contournement de fonction table. La fonction est créée sur SQL Server 2008.Le paramètre de requête de texte intégral pour la chaîne de requête Fulltext n'est pas valide

De manière surprenante, j'obtiens une erreur "Le paramètre de requête de texte intégral pour la chaîne de requête Fulltext n'est pas valide" lorsque je recherche un texte simple, par ex. "Manager"

J'ai utilisé SQL Server Profiler et j'ai découvert que LINQ générait le paramètre nvarchar (4000) au lieu de nvarchar (250) qui est dans ma fonction.

La plus grande surprise est venue quand j'ai changé ma fonction de SQL Server ainsi elle accepte le paramètre comme nvarchar (4000) au lieu de nvarchar (250) et le problème est résolu.

Je jouais aussi pour changer le paramètre en nvarchar (2000) et moins mais cela ne fonctionnait pas non plus.

Est-ce que quelqu'un sait pourquoi cela se comporte de cette façon?

Mise à jour le 18 Novembre 2013 - bonnes nouvelles et de mauvaises nouvelles

Bonnes nouvelles - Je suis maintenant en utilisant Entity Framework 6 pour cet exemple particulier et ce ne sont pas plus besoin d'utiliser nvarchar (4000)

Mauvaises nouvelles - Vous devez utiliser la place nvarchar (max) :-(

+0

La seule chose qui vient à l'esprit est que vous avez la structure de la table de base de données mises en cache lors de la conception de dbml. Vous pouvez le changer complètement en nvarchar (max) et le remapper dans votre application. –

Répondre

5
+0

Il y a un rapport de bogue pour ceci à [https://connect.microsoft.com/SQLServer/feedback/details/585759/lint-to-sql-parameter-resized](https://connect.microsoft.com/SQLServer/ feedback/details/585759/lint-à-sql-parameter-resized) –

+0

Au cas où quelqu'un trouverait cela (comme je viens de le faire), la solution "simple" est de rendre votre paramètre de fonction "VarChar (8000)". On dirait que le bug est toujours en place. Même LinqPad a dit que mon param de L2S était VarChar (1000), mais j'avais toujours des erreurs. –

+0

Cela semble être lié à la version .NET que vous utilisez. J'ai mis à jour le projet vers .NET 4 et j'ai eu ce problème. Je l'ai rétrogradé à .NET 3.5 et le problème a disparu, même si je continue à utiliser VS 2012. – GSerg

-1

Vous devez vous assurer que la taille des variables varchar (ou nvarchar) est la même dans votre fonction sql et où elles sont déclarées.

Dans mon cas, j'avais une fonction qui déclarait la variable comme nvarchar (100) mais la procédure stockée qui appelait la fonction déclarait la variable transmise comme nvarchar (200). Changer la fonction pour qu'elle soit la même que la variable de procédure stockée l'a corrigé.

Le code ci-dessous montre le cas de non fonctionnement avec les nvarchar de taille inégale.

CREATE FUNCTION [dbo].[udf_FullTextSearch](@searchExpression nvarchar(100)) 
RETURNS TABLE 
AS 
    RETURN 
    SELECT * 
    FROM Company c 
    WHERE contains(c.Name, @searchExpression) 
GO 

DECLARE @searchExpression nvarchar(200) = '"ltd"' 
SELECT * FROM [dbo].[udf_FullTextSearch](@searchExpression) 
+0

Le problème est spécifique à Linq2Sql. Vous ne pouvez pas le résoudre de cette façon. – GSerg

1

Dans mon cas, je devais forcer JAVA à appeler ma table Value-fonction avec correspondance datatype comme ci-dessous

query.setParameter(0, variable, new **StringNVarcharType**() )