>Sergey,
>
>Thank you for that suggestion. I agree with that and it does make the code much easier to read and more manageable. I changed all those IF..ENDIF statemens to DO CASE.. ENDCASE, but I was still experiencing the same issue.
>
>I have been watching the variable "lcStr" in the Watch window and it does indicate the correct value in that window. However, as I said in my first note, I can hover my mouse over several instances of the "lcStr" and see it's value in a tooltip. But when I hover over the lines that are important to the example I am testing:
>
>>CASE !LIKE("*DEHYDRATE*", lcStr) ;
>OR LIKE("*TC*",lcStr)
>
>or this line
>
>>CASE LIKE("RT/DEHYDRATE", lcStr) OR LIKE("DEHYDRATE", lcStr)
>
>no value shows. I can step through it in Debug and see in the Watch window that lcStr = RT/DEHYDRATE but it simply ignores the CASE that it's suppose to step into. I don't understand it.
>
>I have changed my "CASE" logic to avoid those situations and now I have all the expected possibilites covered. If something "un-interpretable" is found, the user will be prompted with a question as to whether or not they want to continue and will be shown the "un-interpretable" data.

Is it possible that lcStr is padded with spaces on the right (lcStr = "RT/DEHYDRATE ")? In this case ? LIKE("RT/DEHYDRATE", lcStr) OR LIKE("DEHYDRATE", lcStr) will return .F.

>You also mentioned:
>>>LIKE("RT/DEHYDRATE", lcStr) is the same as "RT/DEHYDRATE" == lcStr.
>Is one method better than the other? Is there a reason I should use one method in some instances and another method in others?

First, I wasn't sure if you where aware about that. Second, when I saw LIKE() w/o wildcard characters I started wondering if you forgot to add them. It all comes down to readability. If you don't need wildcards why use LIKE() function?
Tell you truth I almost never use this function. Instead of LIKE("*DEHYDRATE*", lcStr) I would use ("*DEHYDRATE*" $ lcStr). It's just my personal preference but again I think it makes code more readable. :)