An unknown full-text failure (80004005) occurred in functi..

We are using Full Text Search on our production SQL Server
(Active/Active Cluster, MSSQLSERVER EE).

Within the last week we have not been able to rebuild the FTC on any
database on one node/instance. We get the following message:
Server: Msg 7608, Level 17, State 1, Procedure sp_fulltext_database,
Line 46
An unknown full-text failure (80004005) occurred in function
EnumCatalogs on full-text catalog ''.

This roughly corresponds with when we moved a database from one
logical drive to another by means of detach/attach. I believe that
there is now some inconsistency between the FTDATA folders, the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0 registry, and the FTC
metadata in sysfulltextcatalogs. It's taking me a while to verify
this because off the large number of databases and FTDATA folders on
multiple drives.

The first question is that when calling "sp_fulltextdatabase 'enable'"
is the consistency between database, registry and folder being
verified by SQL Server or MsSearch? It seems to be because I can't do
a "sp_fulltextdatabase 'enable'" in a new database now on the instance
in question, which leads me to believe that when there is one
inconsistency you won't be able to make catalog metadata changes until
the inconsistency is resolved.

The second question is, if the first question is true, is there an
easy or even automated way to check the consistency and possibly
repair it?

Jim Roberts
Hire.com
Senior Database Engineer
MCSE, MCDBA

Jim,
You are mostly correct... When you moved your FT-enabled table via
detach/attach that "broke" not only the Registry key, FTDATA folder, but
also caused inconsistency system tables, not only sysfulltextcatalogs, but
sysdatabases, sysobjects, sysindexes and syscolumns.

To resolve this takes several steps, that can include modifying the registry
as well as updating all affected files and system tables via manually
de-referencing the FT Catalog info from the Registry, FTDATA folder as well
as from all system tables. I have a procedure to do this, that because of
the above changes is not documented and if incorrectly executed can cause
problems.

So, while this procedure has worked very successfully in many instances,
while I was at Microsoft as well as in this newsgroup, caution is advised.
First of all, I need to know the exact version of SQL Server, you are using.
Could you post the full output of SELECT @@version -- as the procedure is
very specific to the SQL Server version. Additionally, you should backup
your detached/attached database as well as make a Registry backup of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\ hive.

Regards,
John


"Jim Roberts" wrote in message

 > We are using Full Text Search on our production SQL Server
 > (Active/Active Cluster, MSSQLSERVER EE).
 >
 > Within the last week we have not been able to rebuild the FTC on any
 > database on one node/instance. We get the following message:
 > Server: Msg 7608, Level 17, State 1, Procedure sp_fulltext_database,
 > Line 46
 > An unknown full-text failure (80004005) occurred in function
 > EnumCatalogs on full-text catalog ''.
 >
 > This roughly corresponds with when we moved a database from one
 > logical drive to another by means of detach/attach. I believe that
 > there is now some inconsistency between the FTDATA folders, the
 > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0 registry, and the FTC
 > metadata in sysfulltextcatalogs. It's taking me a while to verify
 > this because off the large number of databases and FTDATA folders on
 > multiple drives.
 >
 > The first question is that when calling "sp_fulltextdatabase 'enable'"
 > is the consistency between database, registry and folder being
 > verified by SQL Server or MsSearch? It seems to be because I can't do
 > a "sp_fulltextdatabase 'enable'" in a new database now on the instance
 > in question, which leads me to believe that when there is one
 > inconsistency you won't be able to make catalog metadata changes until
 > the inconsistency is resolved.
 >
 > The second question is, if the first question is true, is there an
 > easy or even automated way to check the consistency and possibly
 > repair it?
 >
 > Jim Roberts
 > Hire.com
 > Senior Database Engineer
 > MCSE, MCDBA