Skip to main content
Version: Next

Full-Text Search Errors After a SQL Server Upgrade or Restore

Cortex runs keyword (quick) search against your archive database using SQL Server's full-text search feature. When the full-text engine on the SQL Server instance is unhealthy, keyword search fails and Cortex reports the underlying SQL Server error instead of returning results.

This is rare, but it does happen. It shows up most often in three situations:

  • The SQL Server instance was upgraded in place to a newer major version.
  • A database backup was restored onto a much newer version of SQL Server than the one it was taken from.
  • The archive database was moved or attached to a different SQL Server instance.
note

Upgrading the SQL Server that hosts your archive database or your Cortex database is supported, and almost always works without any action on your part. Full-text search is the one component that occasionally does not survive an in-place upgrade or a restore across a large version gap - which is why SQL Server names it explicitly in the error message.

What the Error Looks Like​

A keyword search fails and Cortex reports an error containing something like:

An error has occurred during the full-text query. Common causes include: word-breaking errors or timeout, FDHOST permissions/ACL issues, service account missing privileges, malfunctioning IFilters, communication channel issues with FDHost and sqlservr.exe, etc.

The SQL Server error number behind this is 30010. After an in-place upgrade the message may also add a hint such as "If recently performed in-place upgrade to SQL2025" - which points straight at the cause.

Why Cortex Does Not Switch to a Slower Search Automatically​

Before using full-text search, Cortex checks two things: whether the full-text feature is installed on the instance (FULLTEXTSERVICEPROPERTY('IsFullTextInstalled')), and whether the table being searched has a full-text index. If either of those is missing, Cortex automatically falls back to a slower "contains" search and users keep getting results.

An engine that is installed but failing at runtime is a different case. Both availability checks pass, so Cortex has no way of knowing the query will fail, and the error reaches the user instead. That is why this class of problem always has to be worked through on the SQL Server itself.

If users instead see "Full-Text search is not installed on the SQL Server", the feature was never added to the instance. That is a different problem: it has to be added through SQL Server setup before keyword search can use an index.

Step 1 - Confirm the Full-Text Feature Is Installed​

Run this on the SQL Server:

SELECT SERVERPROPERTY('IsFullTextInstalled');

A result of 1 means the feature is present. A result of 0 means it is not installed on the instance, which puts you in the "not installed" case described above rather than the runtime-failure case this page covers.

Step 2 - Check the Full-Text Filter Daemon Service​

Full-text queries are not processed inside sqlservr.exe. They are handled by a separate Windows service on the SQL Server:

SQL Full-text Filter Daemon Launcher (MSSQLFDLauncher)

On the SQL Server, open Services and confirm this service exists and is Running. If it is stopped, or is failing to start, full-text queries fail with exactly the error above. Two causes are common:

  • The account the service runs under had its password changed, so the service can no longer log on.
  • The service, or the filter daemon host process (fdhost.exe) it launches, lost the permissions or ACLs it needs during an upgrade or after the database was restored to a different server.

Step 3 - Restart, Then Retest​

  1. Restart the SQL Full-text Filter Daemon Launcher service.
  2. Retest the same keyword search in Cortex.

If the error is still there, restart the SQL Server service itself and retest. Restarting re-establishes communication between SQL Server and the filter daemon, and in many cases clears the error outright.

Step 4 - Check the Catalog and Indexes​

Run these against the archive database:

SELECT * FROM sys.fulltext_catalogs;
SELECT * FROM sys.fulltext_indexes;

The tables Cortex searches should each have an enabled full-text index, with a catalog that is not stuck mid-population.

To see whether an index population has failed or is stuck, an administrator with server-level permission can run:

SELECT * FROM sys.dm_fts_index_population;

If that returns a permission error, it is the login missing the server-level VIEW SERVER STATE permission. It has nothing to do with searching and can simply be skipped - the two checks above are the ones that matter here.

Step 5 - Rebuild the Full-Text Catalog​

If the engine looks healthy but queries still fail, rebuild the catalog. Get its name first:

SELECT name FROM sys.fulltext_catalogs;

Then rebuild it, off hours, under an administrator account:

USE [YourArchiveDatabase]
GO
ALTER FULLTEXT CATALOG [YourFullTextCatalog] REBUILD
GO

A catalog rebuild re-reads every full-text-indexed table in the database. On a large archive it can take a while and use noticeable CPU on the SQL Server. Once started it runs in the background; to confirm it has finished:

SELECT FULLTEXTCATALOGPROPERTY('YourFullTextCatalog', 'PopulateStatus');
-- 0 = idle (rebuild complete)

A rebuild only rewrites full-text indexes. Cortex reads your archive database but never writes to its tables, so this cannot affect your archived data.

A single table can also be repopulated on its own:

ALTER FULLTEXT INDEX ON [YourTable] START FULL POPULATION;

Step 6 - Reproduce It Directly​

To tell whether the whole engine is affected or just one table, run a full-text query in SSMS against the archive database, on the table behind the business object that failed:

SELECT * FROM FREETEXTTABLE([YourTable], *, 'test');
  • Same error - the full-text engine itself is the problem; work through the checks above.
  • It succeeds - the issue is specific to a particular table or catalog. Compare the failing object's index (Step 4) against one that searches correctly.

Step 7 - Check the Logs​

Look at the Windows Event Viewer (Application log) on the SQL Server, and the SQL Server error log, for entries around the time a search failed - especially anything naming fdhost.exe or the filter daemon. These usually identify the component that broke.

Keeping Search Working While You Fix It​

Keyword search is not the only way to find records, and there are two ways to keep searching while the full-text engine is being repaired:

  • Comparison filters in the search builder do not use full-text search at all, so they keep working normally.
  • Fallback Mode (Slow) runs a keyword search as a LIKE-based scan of the object's text columns instead of using the full-text index. It returns correct results - often broader ones - without needing a healthy full-text engine, at the cost of speed on large archives.

Fallback Mode is available from the search settings menu on the Search page, so a user who needs a keyword search right now can select it. In newer Cortex versions a Cortex administrator can also configure an archive data source to always use Fallback Mode for quick search, which keeps searching looking normal for everyone until the SQL Server side is fixed. See Searching and Data Sources.

When to Contact Support​

If the engine passes every check above and the error still returns after restarting SQL Server and rebuilding the catalog, contact Synapse Software support with:

  • The Cortex version you are running.
  • The full error text, including the SQL Server error number if you have it.
  • Your SQL Server version, and whether it was recently upgraded in place or had a database restored onto it.
  • The output of the checks in Steps 1, 2 and 4.
  • Any related Windows Event Viewer or SQL Server error log entries.

See Also​