Problema com SQL Server 2000 full-text search (FTS) accent sensitive

For english, see here.

Ontem perdi um belo tempo tentando resolver um problema que não me era estranho, mas não me lembrava. Depois de muito tempo queimando neurônios, um estalo me fez lembrar de tudo. Desta vez vou blogar para não esquecer mais e para registrar para os leitores (e usuários do Google) a solução, bastante estranha, mas eficaz.

Quem me deu a dica na época foi um brasileiro, em alguma lista de discussão (se bobear na própria CF-Brasil), mas agora não consigo me lembrar de quem (caramba, estou precisando tomar fosfosól). Ele merecia os créditos, por isso se você souber quem foi, me avise.

O SQL Server 2000 (assim como outros bancos de dados mais parrudos) oferecem um interessante recurso chamado Full-text search (também chamado de “fulltext”, ou simplesmente FTS). As buscas do tipo full-text são mais rápidas (especialmente em tabelas grandes) e mais inteligentes que as feitas usando o bom e velho comando SQL LIKE. Entretanto no SQL Server 2000 existe um bug (não necessariamente do SQL Server, mas de um componente dele, veja abaixo) que não permite se realizar buscas full-text que sejam accent insensitive (que não diferencia palavras acentuadas das não acentuadas), mesmo se o seu collation do seu banco, tabela ou coluna seja explicitamente configurado como AI_CI (accent insensitive e case insensitive).

O problema parece estar no Microsoft Search Service, responsável pelas buscas do tipo full-text search para o SQL Server 2000. O SQL Server 2000 SP3a vêm com uma versão do Microsoft Search que não realiza buscas do tipo accent-insensitive, ou seja, ele diferencia palavras de acordo com sua acentuação, dificultando bastante a busca, uma vez que as ocorrências de, por exemplo, “Fábio”, serão diferentes das de “Fabio” (sem acento). A versão do mssearch.exe (responsável pelos processos de indexação e busca) que vem com o SQLServer 2000 é a 9.107.x.x.

Ao que parece, outros produtos da Microsoft também utilizam o Microsoft Search, porém com versões mais atualizadas, que suportam buscas accent insensitive, justamente o que precisava. O porquê da Microsoft não ter incluido esta(s) versão(ões) mais atualizada(s) no SP3 do SQL Server 2000 é um mistério para mim, porque na época do lançamento deste service pack certamente já existiam versões mais atualizadas. Talvez o diáologo abaixo, encontrado num transcript deste WebCast e um trecho deste artigo expliquem:

No Webcast:

Otto: Is there any way to have accent insensitive searches? Currently I have to preprocess the search to normalize foreign-accented characters.

Follow-up answer: This issue was not fixed in Service Pack 3.

No artigo:

T-SQL improvements–Look for thesaurus support as well as a full-text index creation syntax very similar to the CREATE INDEX syntax used for tables. You may realize that the current versions of Search SQL don’t handle noise words or accents well. Happily, the version of Search SQL that ships in SQL 2005 solves these problems. You can also selectively query one or more columns in your full-text query.

Ou seja, teríamos que esperar o Yukon (SQL Server 2005) para corrigir o problema… Nada disso!

Eis que para salvar nossa pele, existe o Microsoft SharePoint Portal Server 2001 (nem existe mais à venda). Este software de servidor é um destes que tem uma versão atualizada do tal Microsoft Search Service. Nele encontramos a versão 10.145.x.x, que resolve o problema das buscas accent-sensitive. A solução portanto é extrair o Microsoft Search do SharePoint e usá-la. Para isso basta seguir estas instruções. Mas como encontrar o SharePoint Portal Server 2001?

Bem, neste caso tive que fazer uma coisa muito feia, mas bastante comum em terra-brasilis (continue lendo). Como eu sou um cara estressado, e fico com pulga atrás da orelha por não saber registrar dlls e entradas no registry corretamente, resolvi instalar e logo em seguida desinstalar o SharePoint Portal Server 2001 que, confesso, consegui baixar de um site piratão, destes onde se lê “appz” e se reza para não pegar nenhum vírus ao se navegar. Afinal de contas, o que eu preciso não é o SharePoint Server, mas sim a versão atualizada (“corrigida” seria o termo mais adequado) do Microsoft Search, que é gratuíto e parte integrante do SQL Server 2000 Standard, do qual tenho licença (sei que tem gente que não vai acreditar, mas quem me conhece sabe que eu tenho sim). Mesmo assim, vale lembrar que o SharePoint Portal Server 2001, apesar de antigo, existe em versão trial, limitada a 120 dias, mas que atualiza o Microsoft Search de qualquer maneira, mesmo que você desinstale o dito cujo por completo. Eu tinha este CD (que veio num daqueles pacotes MSDN) e poderia tê-lo usado perfeitamente (e legalmente), mas infelizmente joguei fora.

Ao instalar e desinstalar o MS SharePoint Server 2001, seja a versão full ou a trial, o Microsoft Search continua atualizado na 10.145.x.x (ele não retorna à versão antiga) e as buscas do tipo fulltext são agora accent-insensitive. Wonderfull. Nada que uma boa “”reengenharia”” chinfrim não resolva.

Fica aí a dica para os mais desesperados, como eu. 😉

UPDATE: o trial do SharePoint Server 2003 também oferece a versão atualizada do Microsoft Search e pode ser baixado aqui.

Sourceless & Package Creation

Clarifying Sourceless Deployment And Deployment Package Creation

Esse assunto inclusive também foi alvo de dúvidas na lista CF-Brasil.

Validação CFFORM e submit via onClick, bug ou o que?

Semana passada estava desenvolvendo um website quando surgiu a necessidade de se submeter um formulário (criado com CFFORM) com um link de texto, ao invés de uma imagem ou tradicional botão de submit. Pensei: nada mais simples. Basta chamar a função submit(); invocando JavaScript direto na tag <a> (<a href=”JavaScript:submit();”>) ou usando o método OnClick (<a href=”#” OnClick=”submit();”>).

Mas acontecia um problema estranho: ao se clicar no link para submeter o formulário, toda em qualquer validação necessária para este formulário (justamente o que mais nos interessa na tag CFFORM) era ignorada e o formulário submetido assim mesmo. Campos obrigatórios que eram, por exemplo, deixados em branco, eram submetidos assim mesmo, ignorando a validação gerada pelo CFFORM (atributo required=”yes”).

Confira o problema aqui. Googlei a respeito mas não encontrei nada, apenas alguns relatos de problemas parecidos, porém sem solução. Para resolver o meu problema imediato, acabei encontrando uma forma de contorno (workaround) relativamente simpls, vulgo gambiarra, que funciona bem e que consiste na criação de uma nova função, exclusiva para (1) forçar as verificações pendentes (onSubmit) e (2) submeter o formulário na seqüência, assim (supondo que o seu formulário seja nomeado como “formulario”):

<script language="JavaScript">
function submitform() {
if (_CF_checkformulario(formulario))
formulario.submit();
}
</script>

O workaround pode ser visto em funcionamento também aqui. Na seqüência postei o meu problema na CF-Brasil e tive a ajuda do Fernando Barros que me disse acertadamente não se tratar de um bug do CFFORM, mas sim de algum outro elemento, muito provavelmente o browser, que não estava seguindo uma recomendação do W3, com base nesta informação. É difícil dizer se o problema é simplesmente este, uma vez que a recomendação é bastante clara: o evento submit deve submeter o formulário (o que efetivamente acontece), mas não fala nada sobre eventuais handlers pendentes e existentes para este mesmo formulário. IE, Mozilla/Firefox e Opera apresentam o mesmo problema. Como JavaScript não é necessariamente uma área cujas recomendações do W3 valham, procurei na Nestcape (mãe do JavaScript) qualquer informação a respeito e de novo acertei a água, nada.

Até agora não encontrei nenhuma explicação definitiva e conclusiva. Por isso pergunto: alguém aí sabe de alguma coisa? Poderia nos dar uma luz?