Thomas, I tried increasing the _MAXTASK_STACK from 1024 to 4096 kB, but the Stack overflow problem persists. However, I am still struggling with understanding why the procedure cannot be created, since:
- If I create a procedure that references a view that my user owns, that in turn accesses tables that another user owns but has granted SELECT on to my user, I get a Stack overflow error. - If I create *the exact same procedure* that references a view that my user owns, that in turn accesses tables that my user also owns, it works flawlessly. - The procedure itself does nothing more complex than select all rows from the view and return them as a cursor. The view that is being referenced is complex in that it joins five tables together. Is the figuring out of access rights to objects used in a procedure such a resource intensive task that it would cause a stack overflow virtually all by itself? Hope you can shed some more light on the issue! Johan H -----Original Message----- From: Anhaus, Thomas [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 12:48 AM To: '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Subject: RE:Stack overflow when creating BBPROC Johan Hellgren wrote : >we've run into a strange problem when creating a stored procedure that >accesses views and tables like this: >- User A has created a set of tables and grants SELECT access to them to >user B. >- User B creates a view that references those tables that user A owns. >- User B then tries to create a stored procedure that returns a cursor by >selecting from the view above. I say "tries" because the CREATE DBPROC >statement fails with a "General error;-918 POS(177) Stack overflow". >- If instead user A creates the view and then the procedure everything works >fine. >Is this a bug, or is it just too complex an operation to calculate the >requisite access rights if the owner of the procedure is not also the owner >of any objects that are used in the procedure? For every statement inside a db-procedure a check is made whether there's enough stack left to prepare/execute the statement. If this is not true, error -918 is returned. This avoids kernel crashes caused by a stack overflow. So it seems that your db-procedure is just too complex for the given stack size. You may increase the parameter _MAXTASK_STACK to avoid the problem. Thomas -- Thomas Anhaus SAP DB, SAP Labs Berlin [EMAIL PROTECTED] http://www.sapdb.org/ _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
