Los campos long varchar son muy útiles para almacenar textos muy largos pero no para trabajar con ellos, hay que conocer sus limitaciones ( que varían bastante según el DBMS ).

Para el caso de SQLServer, el like sobre long varchar está implementado con lo cual es posible programar en GX un foreach del estilo:

&FiltroCampoLong = '%OMBU%'
For each
where campoLong like &FiltroCampoLong
..
EndFor

esto funciona correctamente, retorna las tuplas que contienen la palabra "OMBU" en campoLong. ( la consulta se resuelve en el DBMS a través de una sentencia Select..where campoLong like '%OMBU%' )

Ahora, dependiendo de ciertas configuraciones de SQLServer, este For each podría retornar o no las tuplas que contienen "Ombú", "Ombu", "OMBÚ", "ombú", "ombu".

Para el caso vamos a suponer que queremos que la búsqueda retorne todas esas combinaciones de "Ombú", no..primero vamos a ser un poco menos ambiciosos y vamos a pedir que la consulta no sea sensitiva a mayúsculas, dejamos de lado el problema de los tildes por ahora.

Entonces, lo mas natural parece ser incluir un "Upper" en el where del foreach.

For each
where Upper( campoLong ) like &FiltroCampoLong
..
EndFor

Si ejecutamos la aplicación, parece funcionar bien en unos cuantos casos pero..es extraño que funcione tan bien cuando SQLServer no permite aplicar la función Upper sobre un campo long varchar ( que se corresponde con el tipo "text" de SQLServer ). Bien..la sentencia que genera GX es algo así "Select..WHERE UPPER(CAST([campoLong] AS char(8000))) like..", es decir para poder aplicar el upper, convierte CampoLong en un char(8000) que es lo mas grande que puede ser un char en SQLServer.

Problema..este campoLong es mas grande, está definido en GX como Long varchar de 10 KB con lo cual puede haber pérdida de información en el cast, no es buena idea hacer un upper en este caso puntual...

Otra solución puede ser no poner el where en el foreach, es decir traerse toda la tabla y luego resolver el upper en el cliente pero si la tabla es grande la performance es mala.

Bien, ¿que tal si le pedimos a SQLServer que cuando le llegue la consulta "Select..where campoLong like '%OMBU%' " no distinga mayúsculas en campoLong? eso si funciona bien. Si van al Enterprise Manager y prueban crear una BD..en el cuadro de diálogo les aparece una opción que se llama "Collation name", esa opción básicamente es para indicar el mapa de caracteres que va a tener la base ( afecta por ejemplo si en la BD se van a poder almacenar "Ñ" o no ) y el collation también define entre otras cosas la forma en que se resuelven las comparaciones sobre campos char/varchar/long,nchar..en particular si estas comparaciones serán sensitivas a mayúsculas y tildes.

Para que nuestra búsqueda GX no diferencie de mayúsculas ni tildes hay que usar el collation "Modern_Spanish_CI_AI" ( "Modern_Spanish" es el collation recomendado para Uruguay, "CI" es para que sea case insensitive y AI es para que sea accent insensitive ).

Si la BD ya está creada es más complejo cambiar el collation pero también funciona, hay que:

1) Ejecutar un "ALTER DATABASE nombreBD COLLATE Modern_Spanish_CI_AI" ( con esto no alcanza pues solo vale para próximas tablas y campos que se creen),

2) salvar los datos de las tablas, recrear las tablas (sin indicar collation para que tome el default de la base) y reimportan los datos.

También se puede cambiar el collation de una columna sin cambiar el collation de toda la base pero..se complican las reorganizaciones de Genexus pues hay que acordarse de no recrear el campo que tiene un collation especial, si se puede cambiar el collation para toda la BD..mas práctico.