>>>I know it works <g> But the point was that in our profile logic we had it
>>>in "fld1 between 100 and 200" form, which doesn't work with evaluate. Well, we went into User Maintenance form in production and changed all profiles to be in the "evaluate-friendly" form, but I also wanted to make sure I would not have such problem in the future. See my reply to Sergey with the current code implementation with try/catch and what do you think about it.
>>
>>I think you should move try/catch and evaluate into User Maintenance form to validate the expression on save.
>
>It's a little bit harder in User Maintenance form, since this form doesn't need to open Trans table and I don't want to overcomplicate it. Right now only IT people have access to User profiles. Basically, my manager set all profiles (originally he did it by hand when we didn't have User Maintenance (my form, BTW) in place). He consulted me on several cases, but somehow I missed OR conditions in profiles and only today while we were changing other profiles we found this problem. No wonder we were assigning resolved accounts to this user!
>
>So, this problem with evaluate turned out to be a blessing since we discovered the other problem. On the other hand, I should have been smarter and realize that all these making no sense assignations were the result of a bad profile. But this problem was brought to my attention only yesterday...


I was agree with Sergey (before I read this post), but you should think what will happens if you want to upsize your application to SQL DB. Maybe SELECT is better than just EVALUATE()? Also what will happens if _TALLY is greater than 1 (SELECT returns more than one record)?