2008-10-10 9 views
35

Tengo una consulta que se ejecutó bien en SQL2005 pero mover la base de datos a SQL2008 me da el error del título.7645 Predicto de texto completo nulo o vacío

El código que es el problema es una llamada a CONTAINS, CONTAINSTABLE o FREETEXT con un parámetro vacío. Sin embargo Estoy intentando única llamada o unirse cuando hay un valor como tales

where (@search_term = '' or (FREETEXT(lst.search_text, @search_term))) 

o

left join containstable (listing_search_text, search_text, @search_term) ftb on l.listing_id = ftb.[key] 
    and len(@search_term) > 0 

Sin embargo no puedo encontrar ninguna solución para que esto funcione en SQL2008. ¿Algunas ideas?

Yo sé que puedo hacer SQL dinámico o tener una sentencia if con dos casos diferentes (seleccionar con FT JOIN, sin seleccionar FT unirse. Cualquier solución mejor que no requiere hacer esto?

Respuesta

52

he encontrado la respuesta a esto hoy al convertir mi propia base de datos de SQL Server 2005 a SQL 2008.

Pass "" para su término de búsqueda y cambiar el @search_term = '' prueba sea @search_term = '""' servidor SQL ignorará las comillas dobles y no generará un error.

Por ejemplo, lo siguiente sería en realidad devuelve todos los registros de la tabla de usuarios:

declare @SearchTerm nvarchar(250) 

SET @SearchTerm = '""' 

select UserId, U.Description, U.UserName 
from dbo.Users U 
WHERE ((@SearchTerm = '""') OR CONTAINS((U.Description, U.UserName), @SearchTerm)) 

Si está utilizando .Net, es posible que obtenga una copia de la clase fulltextsearch de E. W. Bachtal. Su sitio es muy informativo: http://ewbi.blogs.com/develops/

+0

Gracias Chris, que lo fijó! –

+0

Gracias, hombre ... ¡has guardado mis HORAS! Buen día; – effkay

+3

(@SearchTerm = '""') predicado agrega una cantidad extrema de lecturas y el tiempo de espera de consultas ocasionalmente (como lo notó whiplashtony) –

14

Esta solución no funcionó para mí en SQL 2008. La respuesta parecía bastante clara y se consideró útil, pero me daría tiempos de espera en una tabla con registros de 2M. De hecho, bloqueó un servidor que ejecutaba la consulta en SSMS.

No parecía gustarle el quirófano en la cláusula where, pero podía ejecutar bien la consulta separando las condiciones.

Terminé usando UNION con éxito como solución alternativa.

declare @SearchTerm nvarchar(250) 

SET @SearchTerm = '""' 

select UserId, U.Description, U.UserName 
from dbo.Users U 
WHERE ((@SearchTerm = '""') 

UNION 

select UserId, U.Description, U.UserName 
from dbo.Users U 
WHERE CONTAINS((U.Description, U.UserName), @SearchTerm)) 
+3

Probablemente el problema se debió a que el que tengo no está de ninguna manera optimizado . Últimamente he descubierto que usar UNIONs en lugar de OR en las cláusulas WHERE se ejecuta varias veces más rápido.Así que +1 – NotMe

+0

Tuve una consulta con toneladas de LIKE y comodines líderes que funcionaba como un perro. Probé la indexación de texto completo, que no ayudó en absoluto. Usar UNIONs en lugar de ORs obtuvo mi consulta de ~ 15 segundos a menos de 1. +1 !!!! – Melanie

+0

¿Qué sucede si tengo una unión interna entre dos tablas y quiero hacer una búsqueda de texto completo en las dos tablas? eso significa que necesitaré alrededor de 3-4 uniones? –

1

El problema con FTS y el operando OR se corrigió en SP2 CU4. La condición O debería ejecutarse bien sin tener que UNIÓN si está en ese nivel o más tarde. Probamos una actualización muy reciente de SP2 CU8 y FTS funciona con OR ahora. Además, las búsquedas como 3.12 que fallarían antes ahora funcionan bien.

0

AÑADIR comillas dobles. Puede verificar la cadena vacía y luego agregarle comillas dobles.

Set @search_term = case when @search_term = '' then '""' else @Address End 

Aquí tiene -

where (@search_term = '""' or (FREETEXT(lst.search_text, @search_term))) 
Cuestiones relacionadas