I think I prefer SSIS also. I meant scheduled SQL Job, not Windows task.
I saw a suggestion of this in a different thread. Just about to go look at...

I would like to have a Scheduled task of some kind to export TXT files to a client site, running every morning.

My "old school" method is search all databases for a character string among objects (SPs, Views...)

exec sp_MSforeachdb 'use [?] select ''?'' as dbName, name as...

REALISED SP1 Was Not Installed. Installing Now. I hope that prevent a recurrence.

SQL 2016: Ver 13.0.1601.5
16 Gig of RAM

Here's sp_configure:
name minimum maximum config_value run_value
access check cache bucket count 0 65536 0 0
access check cache quota 0 2147483647 0 0
Ad Hoc Distributed Queries 0 1 0 0
affinity I/O mask -2147483648 2147483647 0 0

Data is just about exactly the same. The Stage database was copied to the new server for testing, when the difference in performance was noticed.

I think you and others are correct that it's not Full-text causing the problem, rather the code below, is not making use of the regular indexes.
However on our "Stage"...

I believe the denormalization idea was to put all the search data in 1 table, in a separate database, so that the production tables would not be impacted by searching....

Here's the Actual execution plan from our "Stage"server. Slightly different for some reason, and completes in 2 seconds instead of 30 seconds.
The "Stage" server is an old SQL 2005...

30 minutes after the failed .NET 3.5 install, I suddenly started getting all the backed up emails.... Very strange.

So even though I have .NET 4.5, I still need 3.5 for SQL Mail on SQL 2016 ??
I am having the same problem getting mail to work.
Everything else...

How do you know the indexes are not being used in the actual execution plan ?
Statistics are set to auto update, and I just ran: update statistics member_search with...

Ooops, Actual plan attached

The table does not have frequent inserts, so  better to have a lot of indexes on all the possible fields they might search by ?

Attached is the execution plan

Strange thing is our old "Stage" physical server running SQL 2005 with 4 gig ram, is blazing fast running the same query against a copy of the database.

The...