Molto spesso quando si realizza un sito che interroghi un database SQL Server 2000, sfruttando i cataloghi full-text per le ricerche, occorre fornire al cliente un client che popoli le tabelle alle quali dal sito è possibile interrogare, perché questi cataloghi non si aggiornano da soli, ma sulla base di uno schedalo.

Dobbiamo quindi fare in modo che da un pannello sia possibile aggiornare l'indice full.text, percchè l'inserimento di nuovi dati o la modifica non aggiornano l'indice. Bisogna farlo manualmente oppure impostare una pianificazione.

Il non aggiornamento del catalogo porta a non trovare i dati che abbiamo appena inserito.

Naturalmente questa soluzione è consigliabile quando si fa un aggiornamento di molti record, magari in una transazione.

Creare un web service

Una soluzione al nostro problema potrebbe essere quella di creare un Web Service che faccia questo per noi:

Public Class UpdateIndexFullText
  Public Shared Function IndexFullText() As Boolean
    Dim conn As SqlConnection = New SqlConnection(connstring)
    Dim Cmd As New SqlCommand("sp_fulltext_catalog", conn)
    Cmd.CommandType = CommandType.StoredProcedure
    With Cmd.Parameters
       .Add(New SqlParameter("@ftcat", SqlDbType.VarChar)).Value = "xml"
     .Add(New SqlParameter("@action", SqlDbType.VarChar, 20)).Value = "start_full"
    End With
    Try
     conn.Open()
     Dim Resisu As Boolean = Cmd.ExecuteScalar
     conn.Close()
     Cmd.Dispose()
     Return Resisu
    Catch exsql As SqlException
     Console.writeline(exsql.Message)
     Throw New Exception("Errore nel popolamento dell'indice Full Text")  
   Catch e As Exception
     Console.writeline(ex.Message)
     Throw New Exception("Errore nel popolamento dell'indice Full Text")
    Finally
     conn.Close()
    End Try
 
  End Function
 
 End Class

La stored procedure che si occupa di ciò è quella di sistema, chiamata sp_fulltext_catalog , accetta 3 argomenti e restituisce 0 se l'esito è positivo e 1 se è negativo.

Vediamola in dettaglio. Gli argomenti che accetta sono @ftcat che indica il nome del catalogo , @action che è l'azione da compiere e @path che indica il percorso dove SQL Server deve memorizzare l'indice, che di solito è la directory predefinita del server.

Quest'ultimo parametro può essere impostato, ma non è detto che vi convenga farlo (il valore di default è null).

Uno sguardo ai books on line

Diamo uno sguardo alla guida per capire meglio come funziona la stored procedure.

 <b>sp_fulltext_catalog</b> [ <b>@ftcat</b> <b>= </b> ] <b>'</b> <i>fulltext_catalog_name</i> <b>' ,</b> 
   [ <b>@action</b> <b>= </b> ] <b>'</b> <i>action</i> <b>'</b> 
   [ <b>, </b> [ <b>@path</b> <b>= </b> ] <b>'</b> <i>root_directory</i> <b>' </b> ]

L'action accetta diversi argomenti:

[ <b>@path</b> <b>=</b> ] <b>'</b> <i>root_directory</i> <b>'</b> 

Quando viene creato un catalogo se il valore che gli passiamo è null, SQL Server utilizzerà il percorso con lasottodirectory Ftdata della directory Mssql, ad esempio C:\Programmi\Microsoft SQL Server\Mssql\Ftdata\.

@path è valido solo quando action è uguale a create, altrimenti va impostato su Null.

Una considerazione che vorrei fare è sul popolamento incrementale ( start_incremental) , che è molto più performante rispetto a quello totale in quanto fa una query solo sugli elementi modificati, naturalmente grazie al campo timestamp che usa per confrontare i record.