> The application should not create stored procedures. The database
>owner should create them in the lab, having first ensured that the
>procedure has SQL privileges for all the operations and objects it
>will touch and any users that are going to execute them have the
>required EXECUTE privileges. (SQL privilege rules apply also to
>objects touched by blocks of PSQL within an EXECUTE BLOCK statement.)

Application creates stored procedures that perform copy of data from
one table to another. All the privileges are set at a runtime of
application.

> When you try to do illegal things in SQL, whether violations of
>access rules or any other exception condition, the engine politely
>returns exceptions to the application. If you are seeing a "hang"
>instead of an exception message, I would guess that your exception
>handlers are swallowing exceptions. They shouldn't, they should
>*handle* them in such a way that the exception condition can be
>fixed.

There is no exception at all - call of procedure that initiates
direct SP execution hangs with no result (MFC: CDatabase::ExecuteSQL).

> But then, one cannot tell from this description whether in fact
>this SP ever gets compiled, i.e., survives a COMMIT call. And in
>Firebird, SPs can't be executed without being compiled and actually
>coming into existence. EXECUTE BLOCK is the nearest Firebird gets
>to running uncompiled PSQL.

Same SP's are created and work normally in case of SYSDBA user and
hang in case of non-SYDBA user.

> >Also such query: UPDATE <sometable> SET BLOCK = (SELECT BLOCK

FROM

> Correct your syntax:
>
> update sometable s
> set s.block = (
> select a.block from anothertable a
> where a.someUID = s.someUID
> )
> where s.someUID = 1
>

:) The problem is not in syntax, I've posted only the pattern of the
real query and if I'd had problem in syntax I'd received error before
the query was executed. In my case the same query is executed
normally under SYSDBA user and hangs when it is executed under non-
SYSDBA user.

> >P.S. Also this problem can be reproduced with FB 2.0.0, FB 2.0.1

and

> >2.0b ODBC FB driver.
>
> That's not surprising. ;-)

That is not informative.