External Class Exception

I am calling a custom assembly from within my RDL. If that class raises an
Exception I would like to catch the exception in my call to the RS Web
Service method RenderReport.
Is this possible. Or is it always caught by the report?Report server will always catch and wrap your exception.
In some cases report server will stop report processing (for example if
exception occured in grouping or filter expression); in other cases (text
box value) it will result in #Error and report execution will be continued.
If report processing was stopped Render will return error information.
If report was processed with #Errors then Render will return collection of
warnings
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dlloyd" <Dlloyd@.discussions.microsoft.com> wrote in message
news:8F3A380B-1E43-43D7-8C72-B0E68FCCFB78@.microsoft.com...
> I am calling a custom assembly from within my RDL. If that class raises an
> Exception I would like to catch the exception in my call to the RS Web
> Service method RenderReport.
> Is this possible. Or is it always caught by the report?|||Thank you for the response Alexandre...
The problem is I don't want the exception to end up in an #error in the
textbox. I want the exception rasied up to the software that made the call to
render that report.
With an exception that occurs in a textbox is there a way to throw the
exception back up again?
Dave
"Alexandre Mineev" wrote:
> Report server will always catch and wrap your exception.
> In some cases report server will stop report processing (for example if
> exception occured in grouping or filter expression); in other cases (text
> box value) it will result in #Error and report execution will be continued.
> If report processing was stopped Render will return error information.
> If report was processed with #Errors then Render will return collection of
> warnings
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "Dlloyd" <Dlloyd@.discussions.microsoft.com> wrote in message
> news:8F3A380B-1E43-43D7-8C72-B0E68FCCFB78@.microsoft.com...
> > I am calling a custom assembly from within my RDL. If that class raises an
> > Exception I would like to catch the exception in my call to the RS Web
> > Service method RenderReport.
> >
> > Is this possible. Or is it always caught by the report?
>
>|||There is no clean way to prop exceptions, but you can analyze report
execution warnings and if you see traces of your exception then you can
re-throw it.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dlloyd" <Dlloyd@.discussions.microsoft.com> wrote in message
news:0CD7FA30-69AB-4CA1-A838-985DA6220EFE@.microsoft.com...
> Thank you for the response Alexandre...
> The problem is I don't want the exception to end up in an #error in the
> textbox. I want the exception rasied up to the software that made the call
to
> render that report.
> With an exception that occurs in a textbox is there a way to throw the
> exception back up again?
> Dave
> "Alexandre Mineev" wrote:
> > Report server will always catch and wrap your exception.
> > In some cases report server will stop report processing (for example if
> > exception occured in grouping or filter expression); in other cases
(text
> > box value) it will result in #Error and report execution will be
continued.
> >
> > If report processing was stopped Render will return error information.
> > If report was processed with #Errors then Render will return collection
of
> > warnings
> >
> > --
> > This posting is provided "AS IS" with no warranties, and confers no
rights.
> >
> >
> > "Dlloyd" <Dlloyd@.discussions.microsoft.com> wrote in message
> > news:8F3A380B-1E43-43D7-8C72-B0E68FCCFB78@.microsoft.com...
> > > I am calling a custom assembly from within my RDL. If that class
raises an
> > > Exception I would like to catch the exception in my call to the RS Web
> > > Service method RenderReport.
> > >
> > > Is this possible. Or is it always caught by the report?
> >
> >
> >sql

extended stored procedure catch 22

How does a stored procedure call an extended stored procedure, when the
stored procedure is not in master? (I dont want to give direct permission
to the underlying extended stored procedure).
It seems you have to turn on database chaining, yet there are articles all
over the place saying database chaining is a security risk. "That's quite a
catch, our Catch-22".
Any suggestions for the best approach?
Thanks.Cross-database chaining is off by default in SQL 2000 SP3+ so that you don't
inadvertently open a security hole. You should enable 'db chaining' in your
user database only if you fully understand the security implications.
The main cross-database chaining consideration with an sa-owned user
database is that only sysadmin role members should have permissions to
create dbo-owned objects in that database. The DBA should scrutinize
database objects to ensure that only the intended commands can be executed.
As long as you've locked-down the user database, you can leverage
cross-database chaining to provide needed application functionality while
preventing direct ad-hoc extended stored procedure execution.
Hope this helps.
Dan Guzman
SQL Server MVP
"Neil W." <neilw@.netlib.com> wrote in message
news:e%23oF3H7EFHA.392@.TK2MSFTNGP14.phx.gbl...
> How does a stored procedure call an extended stored procedure, when the
> stored procedure is not in master? (I dont want to give direct permission
> to the underlying extended stored procedure).
> It seems you have to turn on database chaining, yet there are articles all
> over the place saying database chaining is a security risk. "That's quite
> a
> catch, our Catch-22".
> Any suggestions for the best approach?
> Thanks.
>
>|||Hello Neil,
You can refer to the "Backward Compatibility for Cross-Database Ownership
Chaining" topic and "Using Ownership Chains" topic in SQL Books
Online(BOL).
Sophie Guo
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
========================================
=============
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.|||Thanks for the reply, Dan. Am I correct in saying that the only way to
enable extended stored procedures from a UDF/Stored-Procedure is to enable
chaining?
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> Cross-database chaining is off by default in SQL 2000 SP3+ so that you
don't
> inadvertently open a security hole. You should enable 'db chaining' in
your
> user database only if you fully understand the security implications.
> The main cross-database chaining consideration with an sa-owned user
> database is that only sysadmin role members should have permissions to
> create dbo-owned objects in that database. The DBA should scrutinize
> database objects to ensure that only the intended commands can be
executed.
> As long as you've locked-down the user database, you can leverage
> cross-database chaining to provide needed application functionality while
> preventing direct ad-hoc extended stored procedure execution.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Neil W." <neilw@.netlib.com> wrote in message
> news:e%23oF3H7EFHA.392@.TK2MSFTNGP14.phx.gbl...
permission[vbcol=seagreen]
all[vbcol=seagreen]
quite[vbcol=seagreen]
>|||> Am I correct in saying that the only way to
> enable extended stored procedures from a UDF/Stored-Procedure is to enable
> chaining?
Yes, assuming that you don't grant execute permissions on the extended
stored procedure.
Hope this helps.
Dan Guzman
SQL Server MVP
"Neil W." <neilw@.netlib.com> wrote in message
news:lrSQd.5118$SP4.4094@.fe11.lga...
> Thanks for the reply, Dan. Am I correct in saying that the only way to
> enable extended stored procedures from a UDF/Stored-Procedure is to enable
> chaining?
> --
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> don't
> your
> executed.
> permission
> all
> quite
>
>|||And the downside of granting execute permissions on the extended procedures
is that would enable users to execute them directly, correct?
Thanks. I wanted to make sure I understand/
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
enable[vbcol=seagreen]
> Yes, assuming that you don't grant execute permissions on the extended
> stored procedure.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Neil W." <neilw@.netlib.com> wrote in message
> news:lrSQd.5118$SP4.4094@.fe11.lga...
enable[vbcol=seagreen]
while[vbcol=seagreen]
the[vbcol=seagreen]
articles[vbcol=seagreen]
>|||Your understanding is correct.
Hope this helps.
Dan Guzman
SQL Server MVP
"Neil W." <neilw@.netlib.com> wrote in message
news:cxbRd.399$9K6.271@.fe08.lga...
> And the downside of granting execute permissions on the extended
> procedures
> is that would enable users to execute them directly, correct?
> Thanks. I wanted to make sure I understand/
> --
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> enable
> enable
> while
> the
> articles
>