Michel,

I do realize that this has nothing to do with selecting the best index for your particular query timing out.

I was heavily involved for over a dozen years in designing data and statistical models for vehicles, engines, optional equipment [packs] and their used prices (think blue book in the states), even if this was last century. Changing the approach from finding/identifying the specific model as a function of correct information entered by a user to the idea that ***all*** user input is saddled with errors (in very few cases approaching zero) and creating a ranking of all models according to the "error" distance from user given input was one of the things that was a game changer - (and not too easy to implement in last centuries HW). No idea how involved you are there and how much influence you have, but consider such an approach if it is not already implemented.

HTH

thomas

>I have this select:
>
>

>DECLARE @NoEntity Int
>DECLARE @VehicleMake Varchar(30)
>DECLARE @VehicleModel Varchar(30)
>
>SET @NoEntity=19
>SET @VehicleMake='VOLKSWAGEN%'
>SET @VehicleModel='"CABRIOLET*"'
>
>SELECT Client.PrimaryKey
> FROM Client (NOLOCK)
> WHERE Client.NoEntity=@NoEntity AND Client.VehicleMake LIKE @VehicleMake AND Contains (Client.VehicleModel, @VehicleModel)
>

>
>This failed to respond within 5 minutes on the production.
>
>The table has 4 million records
>
>We have indexes on all fields and a full text index on VehicleModel.
>
>Usually, the execution plan would tell us, shown in green, an optimized index to build. In this case, no suggestion is shown.
>
>So, we would normally remove the related indexes and then, the execution plan would be able to react and tell us a recommended index.
>
>In this case, I cannot do that as one of the indexes is the primary key and that primary key is also used in the full text.
>
>What can I do to see what would be the recommended index?