Foro de programación

Otro intento, a ver si a la tercera... :)

• Veo que las diéresis no funcionan bien en 2008, ¿hay diéresis como "ë" en los parámetros? ¿acentos?

• Existe algo llamado thesaurus (diccionario de sinónimos) para definir por ejemplo qué hacer con los acentos. Más información aquí: http://msdn.microsoft.com/es-es/library/ms142491(SQL.100).aspx ¿Están definidos igual?

• En msdn se advierte sobre el lenguaje de los índices, ¿es el mismo en ambas? http://technet.microsoft.com/en-us/library/ms142507.aspx

Creo que con esto puedes comprobarlo (no tengo el entorno searchindex montado)

select * from sys.fulltext_languages

• Contains da un valor númerico entre 0.0 y 1.0, si especificas un límite puedes tratar de ver si está dando valores distintos en un servidor y en otro. Igual poniendo 0.1 puedes verlos todos... en el 2008. Si es así y vas subiendo el número (0.2,0.3,0.4...). Igual el algoritmo que calcula el numerito de marras no da el mismo número para el mismo caso.

A ver si lo pillamos :)

Se me ocurren más pruebas, veo lo del AND y el OR pero con los paréntesis parece que deberían funcionar del mismo modo:

SELECT campo_nvarchar 
FROM dbo.TABLA 
    where fid = @fid        
        AND (CONTAINS(v1, @v1) 
            OR CONTAINS(v2, @v2))


SELECT campo_nvarchar 
FROM dbo.TABLA 
    where (CONTAINS(v1, @v1) AND fid = @fid)
            OR (CONTAINS(v2, @v2) AND fid = @fid)

Otra sería enlazar el servidor de pruebas con el real y lanzar la consulta desde el de pruebas y ver qué resultados da.

EXEC sp_addlinkedserver
@server = ‘produccion’,@srvproduct =’Entorno produccion’,
@provider = MSDASQL,
@provstr = ‘DRIVER={SQL Server};SERVER=172.100.LO_QUE_SEA;UID=usuario;PWD=contrasena;’

SELECT campo_nvarchar 
FROM [produccion].midata.dbo.TABLA 
    where fid = @fid        
       AND (CONTAINS(v1, @v1) 
           OR CONTAINS(v2, @v2))

--Para borrarlo EXEC sp_dropserver ‘produccion’, ‘drologins’

Tiendo a pensar que tiene que ver más en cómo ve los datos que en cómo trate el and y el or.

Sigo pendiente a ver si te puedo ayudar.

Podría ser el collate por defecto. Puedes comprobarlo lanzando esta query

SELECT CONVERT(varchar, SERVERPROPERTY('collation'))

en ambos servidores, si es diferente podrías obligar a uno determinado.

No sé si es respuesta o comentario... Bueno, lo que veo es que ejecutas dinámicamente una select con clausulas contains. Lo del or, así puesto entre paréntesis me parece muy raro que afecte de algún modo. Se me ocurren varias cosas:

• ¿Podría ser que afecte la longitud de los parámetros? Por ejemplo si la longitud definida en producción para los campos fuera mayor y justo la cadena que buscas cae fuera de esa longitud de parámetro, en el entorno de pruebas no las verías. A lo mejor es una comprobación chorra, pero a veces son cosas así las que fallan.

• Comprueba que si no lo ejecutas en dinámico efectivamente pasa lo mismo. Para saber si el error está en cómo interpreta el texto el ejecutor dinámico. Pon el valor que esté fallando a capón, para ver si el problema está en la conversión de los parámetros dinámica.

• Si has llegado hasta aquí... Queda, divide y vencerás, prueba la sentencia a cahitos, primero un contains (con el valor en que te ocurra), luego otro, luego otro... A ver cual es que el que da un resultado diferente.

• También he buscado en la documentación por si el contains se interpreta diferente, pero no he visto nada por ahora... se supone que lo hacen igual :/