rs.exe scripts

I'm a SQL Server DBA and will be playing the role of a
SQL2000 Reporting Services administrator. To tightly
control the environment and keep track of all the changes,
I'm considering to implement a policy that requires all
changes to Reporting Services and reports be released into
production via VB.NET scripts for rs.exe, and all such
scripts be submitted to me for review first.
I'd like to bounce this off you guys to see (1) whether
I'm going overboard, and (2) whether all changes can be
implemented via RS scripts.
JoeAs far as your first question, about going overboard... it's not clear to me
how this policy can be enforced. Users could just run any script, or write
their own app to talk to the server. If you really want to prevent users
from performing certain actions, I recommend using the built in security to
give users only the permissions they need for the actions you want them to
take.
As far as functionality... rs.exe has complete access to the SOAP API.
--
This posting is provided "AS IS" with no warranties, and confers no rights
"Joe Bourne" <anonymous@.discussions.microsoft.com> wrote in message
news:46ae01c4734b$5b917fa0$a401280a@.phx.gbl...
> I'm a SQL Server DBA and will be playing the role of a
> SQL2000 Reporting Services administrator. To tightly
> control the environment and keep track of all the changes,
> I'm considering to implement a policy that requires all
> changes to Reporting Services and reports be released into
> production via VB.NET scripts for rs.exe, and all such
> scripts be submitted to me for review first.
> I'd like to bounce this off you guys to see (1) whether
> I'm going overboard, and (2) whether all changes can be
> implemented via RS scripts.
> Joe|||Thanks, Brian!
I was thinking in the line of SQL Server's DDL vs DML, if
I can make such a similar distinction in SSRS. So
for 'DDL' type of changes, I'll try to enforce the rs
scripting requirement, whereas for 'DML' type of changes,
the users can make whatever changes however they want.
Just like in SQL Server, the users can
insert/delete/update their data with their permissions,
and I really don't care what they do. But when it comes to
schema changes, I make sure that thye submit scripts to me
first.
Now, can I classify SSRS tasks into 'DDL' and 'DML', and
assign security to allow DML changes only?
Joe
>--Original Message--
>As far as your first question, about going overboard...
it's not clear to me
>how this policy can be enforced. Users could just run
any script, or write
>their own app to talk to the server. If you really want
to prevent users
>from performing certain actions, I recommend using the
built in security to
>give users only the permissions they need for the actions
you want them to
>take.
>As far as functionality... rs.exe has complete access to
the SOAP API.
>--
>This posting is provided "AS IS" with no warranties, and
confers no rights
>"Joe Bourne" <anonymous@.discussions.microsoft.com> wrote
in message
>news:46ae01c4734b$5b917fa0$a401280a@.phx.gbl...
>> I'm a SQL Server DBA and will be playing the role of a
>> SQL2000 Reporting Services administrator. To tightly
>> control the environment and keep track of all the
changes,
>> I'm considering to implement a policy that requires all
>> changes to Reporting Services and reports be released
into
>> production via VB.NET scripts for rs.exe, and all such
>> scripts be submitted to me for review first.
>> I'd like to bounce this off you guys to see (1) whether
>> I'm going overboard, and (2) whether all changes can be
>> implemented via RS scripts.
>> Joe
>
>.
>

RS from VBScript/ASP web-app

I have been playing a round with RepServices for some time, creating some
nice, dynamic reports.
Now our pointy-haired boss would like for me to incorporate a few of these
reports into an old internet application, which was developed using VBS/ASP.
This would be a temporary solution, the application will be rewritten using
.NET sometime next fall.
Which options are open to me if I want to satisfy our boss now?
And - how about security?
Do anybody out there have any experience with a scenario like this?You have two options:
1. Generate your reports on the server side of your ASP app using the SOAP
Tookit. You will loose the report toolbar and interactive features.
2. Use URL addressability with custom security extension.
--
Hope this helps.
---
Teo Lachev, MVP [SQL Server], MCSD, MCT
Author: "Microsoft Reporting Services in Action"
Publisher website: http://www.manning.com/lachev
Buy it from Amazon.com: http://shrinkster.com/eq
Home page and blog: http://www.prologika.com/
---
"Leif" <leif.audun.hagen@.officeteam.no> wrote in message
news:eP14QR9yEHA.1296@.TK2MSFTNGP10.phx.gbl...
> I have been playing a round with RepServices for some time, creating some
> nice, dynamic reports.
> Now our pointy-haired boss would like for me to incorporate a few of these
> reports into an old internet application, which was developed using
VBS/ASP.
> This would be a temporary solution, the application will be rewritten
using
> .NET sometime next fall.
> Which options are open to me if I want to satisfy our boss now?
> And - how about security?
> Do anybody out there have any experience with a scenario like this?
>|||Thanks, Teo. I guess it will please you to know that I have ordered your
book. Unfortunately I have not received it yet.
The reason for asking about classic ASP/VBS is that all examples I have seen
to date are written using .NET, which I unfortunately know practically
nothing about.(Time to wake up and smell the coffee...)
I would like to present the user with a list of reports available to the
user group he is mapped to. This relationship I could probably store in DB.
When he has chosen report, I would like to call RS to get a parameter list
in order to display only the relevant parameter fields. In addition I would
like to give the user a few rendering options.
Upon completion, I would like to display the report in an IFRAME or a new
window. (other suggestions)
Could I use a combination of your suggestions to achieve my goal?
SOAP and classic ASP - is it cumbersome, compared to ASP.NET?
"Teo Lachev [MVP]" <teo.lachev@.nospam.prologika.com> skrev i melding
news:Ok6nQ2EzEHA.2012@.TK2MSFTNGP15.phx.gbl...
> You have two options:
> 1. Generate your reports on the server side of your ASP app using the SOAP
> Tookit. You will loose the report toolbar and interactive features.
> 2. Use URL addressability with custom security extension.
> --
> Hope this helps.
> ---
> Teo Lachev, MVP [SQL Server], MCSD, MCT
> Author: "Microsoft Reporting Services in Action"
> Publisher website: http://www.manning.com/lachev
> Buy it from Amazon.com: http://shrinkster.com/eq
> Home page and blog: http://www.prologika.com/
> ---
>|||Leif,
Thanks for ordering my book.
The requirements you describe can be implemented with either approach.
What you need to decide on is how important are the report interactive
features (drilldown, document maps, toggled visibility) and report toolbar
for you. If there are a must, you have no other choice but to use URL
addressability with custom security (that is at least before RS 2005 comes
along). The added bonus of using URL addressability is that you can handle
the role-membership checks in your custom extension. This approach decouples
your application design from RS security since the only thing you have to
change on the application side is calling the LogonUser SOAP API.
If report interactivity is something you can live without, you can consider
SOAP access using the SOAP toolkit. It is not much difficult to implement
than with ASP.NET. In this case, your application has to handle user
authentication and authorization, filter and display reports. Another
advantage (or disadvantage depending on your perspective :-) of this
approach is that you don't have to exit your lethargic state yet since you
don't have learn .NET.
--
Hope this helps.
---
Teo Lachev, MVP [SQL Server], MCSD, MCT
Author: "Microsoft Reporting Services in Action"
Publisher website: http://www.manning.com/lachev
Buy it from Amazon.com: http://shrinkster.com/eq
Home page and blog: http://www.prologika.com/
---
"Leif" <leif.audun.hagen@.officeteam.no> wrote in message
news:u$yO0tWzEHA.924@.TK2MSFTNGP10.phx.gbl...
> Thanks, Teo. I guess it will please you to know that I have ordered your
> book. Unfortunately I have not received it yet.
> The reason for asking about classic ASP/VBS is that all examples I have
seen
> to date are written using .NET, which I unfortunately know practically
> nothing about.(Time to wake up and smell the coffee...)
> I would like to present the user with a list of reports available to the
> user group he is mapped to. This relationship I could probably store in
DB.
> When he has chosen report, I would like to call RS to get a parameter list
> in order to display only the relevant parameter fields. In addition I
would
> like to give the user a few rendering options.
> Upon completion, I would like to display the report in an IFRAME or a new
> window. (other suggestions)
> Could I use a combination of your suggestions to achieve my goal?
> SOAP and classic ASP - is it cumbersome, compared to ASP.NET?
> "Teo Lachev [MVP]" <teo.lachev@.nospam.prologika.com> skrev i melding
> news:Ok6nQ2EzEHA.2012@.TK2MSFTNGP15.phx.gbl...
> > You have two options:
> >
> > 1. Generate your reports on the server side of your ASP app using the
SOAP
> > Tookit. You will loose the report toolbar and interactive features.
> > 2. Use URL addressability with custom security extension.
> >
> > --
> > Hope this helps.
> >
> > ---
> > Teo Lachev, MVP [SQL Server], MCSD, MCT
> > Author: "Microsoft Reporting Services in Action"
> > Publisher website: http://www.manning.com/lachev
> > Buy it from Amazon.com: http://shrinkster.com/eq
> > Home page and blog: http://www.prologika.com/
> > ---
> >
>