Reject user from SQL-DB

[JB]

Phil Mayers:
> JB wrote:
>> I'm sorry, I have to ask again. Have you found a way to let the  
>> reply query know that the user has already been rejected in the  
>> check-query? I'm trying to avoid executing the same queries twice  
>> and also to avoid using temporary tables.
>
> I thought I'd answered this?
> """What you could do is place a local attribute in the check items,  
> then copy it to the reply items in an unlang section..."""
> Which you said worked in a later email

Sorry if I haven't made myself clear enough. These were two different  
things.

On the on hand, I wanted to return a Reply-Message to the user which  
is set in one of the two queries, which works fine the way you proposed.

On the other hand, I wanted to avoid executing unnecessary sub-queries  
in the reply query (a stored procedure in my case), or the reply query  
itself, if the user has already been rejected in the check query. It  
seems that the reply query is always executed. And if I call the  
stored procedure with attributes like "%{control:Auth-Type}" or "% 
{control:My-Reply}", they don't get resolved although they're set in  
the first query.

In pseudo-code:

Check query: reject user because of reason 'xyz', set My-Attr to  
'xyz'. [works]
If rejected, don't call reply query (or at least call reply query with  
resolved attributes to avoid unnecessary sub-queries) [doesn't work]
If rejected copy My-Attr to Reply-Message [works]

JB