SQL Server's query optimizer will of course use a table scan when selectivity warrants.  If seeks can be performed on indexes, the cardinality would have to be extremely high, likely...

> I thought about switching it over to a temporary table which I can create indexes on earlier, just wasn't sure if

> this was a good idea, as I've...

Left.

Are you sure UNION isn't faster than using the OR?  If the optimizer uses two index seeks, that's got to be a different execution plan from using an OR...

UNION ALL...

"An index seek"?  It should be performing two index seeks or scans with the union statement, and that should be faster than using an OR, which will only scan. ...

So with a UNION it's still scanning the indexes, rather than seeking?  The selectivity of your values may be so low that the optimizer won't seek.  A result set of...

Because of the OR, you'll probably find a UNION faster, as it can seek (instead of scan) on each of the two indexed columns.  3 seconds for inserting 63,000 rows seems...

sp_execute is a system stored procedure used with "prepared" statements from a client.  The number you see is an internal pointer to the execution plan on the server.  The values...

Yes, that's how it works.

That text is referring to tables other than the one with the INSTEAD OF trigger (what they're calling "underlying" and the "base" table, respectively).  They're trying to say that an...

You cannot, of course.

Even if you could change a setting like that in a UDF, you still wouldn't be able to use any functions that depend upon the setting, as...

An INSTEAD OF trigger should work okay for this.  I'm not sure where you got the impression that they happen after AFTER triggers, as that's not correct...

CREATE FUNCTION dbo.f_RepRuns(@InStr varchar(8000),@Remove varchar,@Delimiter char)

RETURNS varchar(8000) BEGIN

DECLARE @OutStr varchar(8000)

IF @Remove = '' SET @Remove = ' '

SET @OutStr = @InStr

WHILE @OutStr LIKE '%' + @Remove + @Remove + '%'

 SET...

No.  See http://support.microsoft.com/?id=319942

Updating to SQL Server 2000 will probably increase your performance.  

SELECT LEFT(YourCol,CHARINDEX(' ',LTRIM(YourCol)))

WHERE LTRIM(YourCol) LIKE '% %'