2011-06-09 2 views
4

J'ai une table avec la recherche de texte intégral activée dans la colonne Titre. J'essaie de faire une recherche pondérée avec un containstable mais j'obtiens un débordement arithmétique pour la valeur Rank. La requête est la suivanteSQL Server 2008 Containstable génère un classement négatif avec weighted_term

SELECT ID, CAST(Res_Tbl.RANK AS Decimal) AS Relevancy , Title 
    FROM table1 AS INNER JOIN 
    CONTAINSTABLE(table1,Title,'ISABOUT("pétoncle" weight (.8), "pétoncle" weight (.8), "PÉTONCLE" weight (.8))',LANGUAGE 1036) AS Res_Tbl 
    ON ID = Res_Tbl.[KEY] 

Lorsque j'exécute cette requête, je reçois: erreur de dépassement arithmétique pour le type int valeur = -83886083125,000076.

Si je supprime l'un des deux ';' dans la fonction ISABOUT, la requête aboutit.

Notez que vous devez obtenir des résultats s'il n'y a aucun résultat, la requête aboutit.

Est-ce que quelqu'un sait comment résoudre ce problème?

Cette question est aussi dba.stackexchange.com

+0

Pourriez-vous ajouter des exemples de données qui recrée le problème? J'ai essayé de créer un échantillon par moi-même, mais j'ai été incapable de le recréer. Aussi, que se passe-t-il si vous déposez le CAST dans votre sélection? – Richard

+0

Si je laisse tomber la distribution je reçois la même erreur. Le problème est à l'intérieur de la fonction CONTAINSTABLE. Je ne peux pas vous fournir de données car les données appartiennent à mon client. Je remarque quelque chose quand je manipule le prédicat. Si je supprime l'un des caractères spéciaux (&,#,;) la requête s'exécute avec succès. – Nico

Répondre

1

Qualifier: Puisque je ne peux pas recréer cela, je suis incapable de savoir à coup sûr si cela va résoudre le problème. Cependant, ce sont des choses que je vois.

Tout d'abord, l'esperluette, le signe dièse et le point-virgule sont des caractères de rupture de mot. Cela signifie que, au lieu de chercher la chaîne "p & # 233; toncle", vous recherchez "p", "233" et "toncle". Clairement, ce n'est pas votre intention.

Je dois présumer que vous avez le texte "p & # 233; toncle" quelque part dans votre jeu de données. Cela signifie que vous avez besoin de toute cette chaîne pour être complète.

Il y a plusieurs choses que vous pouvez faire.

1) Éteignez tous les mots-clés. Vous pouvez le faire en modifiant l'index de texte intégral pour l'éteindre.

Notez que vous devez avoir votre base de données mise à SQL Server 2008 compatibilité pour que cela ne génère pas une erreur de syntaxe:

ALTER FULLTEXT INDEX ON Table1 SET STOPLIST OFF; 

2) Créer une nouvelle liste de mots vides

Si vous créez un STOPLIST vide , vous pourriez être en mesure d'ajouter les mots vides que vous voulez ou copier la liste d'arrêt du système et supprimer les mots vides que vous ne voulez pas. (Je conseillerais la deuxième approche). Cela dit, je n'ai pas pu trouver le & ou # dans la liste d'arrêt du système, donc ils peuvent être codés en dur. Vous devrez peut-être simplement désactiver la liste d'arrêt.

3) Modifiez votre recherche pour ignorer le cas "p & # 233; toncle".

Si vous laissez tomber le "p & # 233; toncle" du ISABOUT et les modifier à "p toncle", il pourrait fonctionner:

'ISABOUT("pétoncle" weight (.8), "p toncle" weight (.8))' 

Ce sont juste quelques idées. Comme je l'ai dit, sans pouvoir accéder au système ou recréer le scénario, nous ne serons pas en mesure d'aider beaucoup.


Quelques informations supplémentaires pour votre plus grand plaisir des recherches:

0

Pour les personnes qui ont obtenu à cette page à la recherche des résultats de rang négatifs retournés par SQL Server, comme je l'ai fait, il se trouve que c Cela arrive si certains de vos termes de match sont trop longs (au-delà de certaines limites de caractères). SQL Server ne se plaindra pas ou ne produira pas d'erreur au moment de la requête, mais le classement sera principalement corrompu, produisant un classement négatif pour certains choix de poids (dans mon cas, avec des valeurs de poids faibles sur les termes superflus). Limitez la longueur du jeton/mot et évitez ce problème (probablement un bogue en profondeur dans la recherche fulltext SQL Server 2008).

Questions connexes