>>>>>

ALTER PROCEDURE [dbo].[InvoicesSelectOutstanding]
>>>>>	WHERE inv_date <= @crt_date
>>>>>		AND inv_printed = 1
>>>>>		AND inv_cancelled is null
>>>>>         -- AND cus_credit = 1
>>>>>	ORDER BY cus_company

>>>>>
....
>>you might try something along
>>and cus_credit*10 = 10
>
>can one multiply a boolean by an integer? Even if you could I'm not sure how that would help as then I will only get credit customers and won't get customers who are not credit customers.

/update:
disregard, if the query is fast WITH the index and slow without, I misread on first take! How many recs filtered out ? might be enough as reason
update/

Frank,

I follow a hunch with a lot of uncertainties ;-)
My main hunch is that the optimizer is thrown off by having cus_credit added into the fray. Similar to forcing join order in Oracle (and eliminating from Rushmore in Vfp) I try to filter not with the column itself, but an expression, in case MS SQL takes the route of walking that specific index first and this is harmful.

Assumptions: as MS-SQL does not have booleans, you went with [0,1] as bit, which AFAIR is a range constricted INT forced into bytes according to the number of bit types in the record. If all of that is correct, calculation should succeed.

Other workable expressions should be

Cast(cus_credit as Int)*10=10
Cast(cus_credit as Char(1))+"!" == "1!"

dropping that index from usage ***in this particular query instance***. MS SQL does not have all the bad side effects of "non-BINARY" boolean index as vfp does (need to move the index file across the wire), but might force a lot of unneccessary I/O as/if the index has low selectivity and the optimizer guesses wrong. Other way to check would be to drop the index on cus_credit - but that might hurt other queries, hence my expression approach.
And I might be totally off base since I only glanced at the SQL as in tl;dr and concentrated on the described behaviour and binary field ;-)