No it'll not be optimized in either case. The expression on the left has to match one of the existing indexes exactly. Or put it other way, You should write select such way that it'll utilize existing indexes or create appropriate indexes if table doesn't have one. If you create index on Seg_Cd than following query will be optimizable.

lcSeq_Cd = "..."
lcUser_Proj_No = "..."
TEXT TO lcSqlStatement TEXTMERGE NOSHOW PRETEXT 15
SELECT PROJ.Proj_No 
	FROM PROJ 
	WHERE PROJ.Seg_Cd == "<<lcSeq_Cd>>" 
		AND PROJ.User_Proj_No == "<<lcUser_Proj_No>>"
	ORDER BY PROJ.Proj_No
ENDTEXT	

BTW, the correct tags for code are < pre> and < /pre> (w/o spaces)

>Ok, in the table PROJ there is an index on the field 'User_Proj_No' as well as an index on the field 'Proj_No'
>
>

lcSqlStatement = "SELECT PROJ.Proj_No " + ;
>                 "FROM PROJ " + ;
>                 "WHERE PROJ.Seg_Cd + ALLT(PROJ.User_Proj_No) == 'G15164' " + ;
>                 "ORDER BY PROJ.Proj_No"

>
>If I change my WHERE clause to just
>
>

"WHERE ALLT(PROJ.User_Proj_No) == '15164' "

>
>Will this take advantage of Rushmore?
>Or does the function negate it?
>Should I create a compound index on the 2 fields?
>Will my original querry then be optimized?