Project Hierarchy and Shared Data Sources

Our desires might be misguided, so I would like to hear what some of the more
learned members have to say:
Issue 1:
It appears that Reporting Services supports a folder paradigm that nicely
models how we desire to organize our reports. However, this folder paradigm
is not supported in Visual Studio .NET. In other words, it does not appear
that I can construct a VS.NET solution that contains folders and sub folders
that describe a tree structure.
While the VS.NET solution is â'flatâ' I can however modify the Properties of
each Report Project and set TargetFolder such that as the projects are
deployed they end up in a hierarchy on the report server.
My question is this: Have any of you â'seenâ' this condition and if so, what
have you learned or what have you done about it? Did you perhaps adopt the
same approach as I, accepting the VS .NET solution structure as â'flatâ' and
use the TargetFolder property to achieve the desired hierarchy on the report
server?
Issue 2:
We desire to use a single shared data source for all of our reports. A
shared data source is contained in a given Report Project. There does not
seem to be a way that I can use one projectâ's shared data source in another
projectâ's report. If we consider the hierarchical folder paradigm described
in Issue 1 (above), it seems the only solution is to establish the same
shared data source in each and every Report Project I create.
I suppose alternatively, that I could dispense with attempting to use a
shared data source entirely. Rather, I would just imbed the same data source
into each and every report developed. My thinking here is somewhat an issue
of reuse/maintenance. If I only need one, I donâ't feel I should have to have
more than one instance across the entire Report Server. This may be contrary
to some of the larger scale objectives of Reporting Services, where perhaps
it is desired that different folders access different data using different
credentials and whatnot. At present, we donâ't even name a real DB Server in
the Connection String, but rather a logical name, which is handled via an
Alias that is established on each of our target environments (Dev, QA,
Staging, Beta, Production) such that the deployed reports/data sources will
point to their appropriate DB.
My question here is: Is it possible to use a single shared data source
across many individual report projects without having to physically copy that
shared data source to each project?You are correct on Issue 1. I have just organized my projects for a 1 to 1
relationship with the folders but if you want the folders organized in a
tree you have to do as you mention here. For SQL Server I just put in the
connection but for other data sources (like Sybase) I put in a file dsn.
For example: FILEDSN=C:\Data\Reports\IWTS\development.dsn
Bruce Loehle-Conger
MVP SQL Server Reporting Services
For Issue number 2 I do the following. Yes I have to have a shared
datasource created for each folder BUT the actual
"Herman K" <HermanK@.discussions.microsoft.com> wrote in message
news:70D2647C-D786-4A5D-80B8-B713B69EAC4A@.microsoft.com...
> Our desires might be misguided, so I would like to hear what some of the
more
> learned members have to say:
> Issue 1:
> It appears that Reporting Services supports a folder paradigm that nicely
> models how we desire to organize our reports. However, this folder
paradigm
> is not supported in Visual Studio .NET. In other words, it does not
appear
> that I can construct a VS.NET solution that contains folders and sub
folders
> that describe a tree structure.
> While the VS.NET solution is 'flat' I can however modify the Properties of
> each Report Project and set TargetFolder such that as the projects are
> deployed they end up in a hierarchy on the report server.
> My question is this: Have any of you 'seen' this condition and if so, what
> have you learned or what have you done about it? Did you perhaps adopt
the
> same approach as I, accepting the VS .NET solution structure as 'flat' and
> use the TargetFolder property to achieve the desired hierarchy on the
report
> server?
> Issue 2:
> We desire to use a single shared data source for all of our reports. A
> shared data source is contained in a given Report Project. There does not
> seem to be a way that I can use one project's shared data source in
another
> project's report. If we consider the hierarchical folder paradigm
described
> in Issue 1 (above), it seems the only solution is to establish the same
> shared data source in each and every Report Project I create.
> I suppose alternatively, that I could dispense with attempting to use a
> shared data source entirely. Rather, I would just imbed the same data
source
> into each and every report developed. My thinking here is somewhat an
issue
> of reuse/maintenance. If I only need one, I don't feel I should have to
have
> more than one instance across the entire Report Server. This may be
contrary
> to some of the larger scale objectives of Reporting Services, where
perhaps
> it is desired that different folders access different data using different
> credentials and whatnot. At present, we don't even name a real DB Server
in
> the Connection String, but rather a logical name, which is handled via an
> Alias that is established on each of our target environments (Dev, QA,
> Staging, Beta, Production) such that the deployed reports/data sources
will
> point to their appropriate DB.
> My question here is: Is it possible to use a single shared data source
> across many individual report projects without having to physically copy
that
> shared data source to each project?
>|||Bruce, did you have a 'finished' reply to my second issue? It seems you got
cut off midstream. I see you said that I would need the datasource to be
present in each folder but...
"Bruce L-C [MVP]" wrote:
> You are correct on Issue 1. I have just organized my projects for a 1 to 1
> relationship with the folders but if you want the folders organized in a
> tree you have to do as you mention here. For SQL Server I just put in the
> connection but for other data sources (like Sybase) I put in a file dsn.
> For example: FILEDSN=C:\Data\Reports\IWTS\development.dsn
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> For Issue number 2 I do the following. Yes I have to have a shared
> datasource created for each folder BUT the actual
> "Herman K" <HermanK@.discussions.microsoft.com> wrote in message
> news:70D2647C-D786-4A5D-80B8-B713B69EAC4A@.microsoft.com...
> > Our desires might be misguided, so I would like to hear what some of the
> more
> > learned members have to say:
> >
> > Issue 1:
> >
> > It appears that Reporting Services supports a folder paradigm that nicely
> > models how we desire to organize our reports. However, this folder
> paradigm
> > is not supported in Visual Studio .NET. In other words, it does not
> appear
> > that I can construct a VS.NET solution that contains folders and sub
> folders
> > that describe a tree structure.
> >
> > While the VS.NET solution is 'flat' I can however modify the Properties of
> > each Report Project and set TargetFolder such that as the projects are
> > deployed they end up in a hierarchy on the report server.
> >
> > My question is this: Have any of you 'seen' this condition and if so, what
> > have you learned or what have you done about it? Did you perhaps adopt
> the
> > same approach as I, accepting the VS .NET solution structure as 'flat' and
> > use the TargetFolder property to achieve the desired hierarchy on the
> report
> > server?
> >
> > Issue 2:
> >
> > We desire to use a single shared data source for all of our reports. A
> > shared data source is contained in a given Report Project. There does not
> > seem to be a way that I can use one project's shared data source in
> another
> > project's report. If we consider the hierarchical folder paradigm
> described
> > in Issue 1 (above), it seems the only solution is to establish the same
> > shared data source in each and every Report Project I create.
> >
> > I suppose alternatively, that I could dispense with attempting to use a
> > shared data source entirely. Rather, I would just imbed the same data
> source
> > into each and every report developed. My thinking here is somewhat an
> issue
> > of reuse/maintenance. If I only need one, I don't feel I should have to
> have
> > more than one instance across the entire Report Server. This may be
> contrary
> > to some of the larger scale objectives of Reporting Services, where
> perhaps
> > it is desired that different folders access different data using different
> > credentials and whatnot. At present, we don't even name a real DB Server
> in
> > the Connection String, but rather a logical name, which is handled via an
> > Alias that is established on each of our target environments (Dev, QA,
> > Staging, Beta, Production) such that the deployed reports/data sources
> will
> > point to their appropriate DB.
> >
> > My question here is: Is it possible to use a single shared data source
> > across many individual report projects without having to physically copy
> that
> > shared data source to each project?
> >
>
>|||To answer your second question, yes you can have the same data source for
mutliple reports in multiple folders, but you need to connect each report to
the data source individually after you publish. You can either do this
manually or write a script. I haven't written a script yet to do this yet,
but someone here might have a code example.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Herman K" <HermanK@.discussions.microsoft.com> wrote in message
news:CAB6F427-B5FD-4711-8CB2-7865E992345C@.microsoft.com...
> Bruce, did you have a 'finished' reply to my second issue? It seems you
> got
> cut off midstream. I see you said that I would need the datasource to be
> present in each folder but...
> "Bruce L-C [MVP]" wrote:
>> You are correct on Issue 1. I have just organized my projects for a 1 to
>> 1
>> relationship with the folders but if you want the folders organized in a
>> tree you have to do as you mention here. For SQL Server I just put in the
>> connection but for other data sources (like Sybase) I put in a file dsn.
>> For example: FILEDSN=C:\Data\Reports\IWTS\development.dsn
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> For Issue number 2 I do the following. Yes I have to have a shared
>> datasource created for each folder BUT the actual
>> "Herman K" <HermanK@.discussions.microsoft.com> wrote in message
>> news:70D2647C-D786-4A5D-80B8-B713B69EAC4A@.microsoft.com...
>> > Our desires might be misguided, so I would like to hear what some of
>> > the
>> more
>> > learned members have to say:
>> >
>> > Issue 1:
>> >
>> > It appears that Reporting Services supports a folder paradigm that
>> > nicely
>> > models how we desire to organize our reports. However, this folder
>> paradigm
>> > is not supported in Visual Studio .NET. In other words, it does not
>> appear
>> > that I can construct a VS.NET solution that contains folders and sub
>> folders
>> > that describe a tree structure.
>> >
>> > While the VS.NET solution is 'flat' I can however modify the Properties
>> > of
>> > each Report Project and set TargetFolder such that as the projects are
>> > deployed they end up in a hierarchy on the report server.
>> >
>> > My question is this: Have any of you 'seen' this condition and if so,
>> > what
>> > have you learned or what have you done about it? Did you perhaps adopt
>> the
>> > same approach as I, accepting the VS .NET solution structure as 'flat'
>> > and
>> > use the TargetFolder property to achieve the desired hierarchy on the
>> report
>> > server?
>> >
>> > Issue 2:
>> >
>> > We desire to use a single shared data source for all of our reports. A
>> > shared data source is contained in a given Report Project. There does
>> > not
>> > seem to be a way that I can use one project's shared data source in
>> another
>> > project's report. If we consider the hierarchical folder paradigm
>> described
>> > in Issue 1 (above), it seems the only solution is to establish the same
>> > shared data source in each and every Report Project I create.
>> >
>> > I suppose alternatively, that I could dispense with attempting to use a
>> > shared data source entirely. Rather, I would just imbed the same data
>> source
>> > into each and every report developed. My thinking here is somewhat an
>> issue
>> > of reuse/maintenance. If I only need one, I don't feel I should have
>> > to
>> have
>> > more than one instance across the entire Report Server. This may be
>> contrary
>> > to some of the larger scale objectives of Reporting Services, where
>> perhaps
>> > it is desired that different folders access different data using
>> > different
>> > credentials and whatnot. At present, we don't even name a real DB
>> > Server
>> in
>> > the Connection String, but rather a logical name, which is handled via
>> > an
>> > Alias that is established on each of our target environments (Dev, QA,
>> > Staging, Beta, Production) such that the deployed reports/data sources
>> will
>> > point to their appropriate DB.
>> >
>> > My question here is: Is it possible to use a single shared data source
>> > across many individual report projects without having to physically
>> > copy
>> that
>> > shared data source to each project?
>> >
>>|||You can certainly share a datasource by using the web API. You can
write a script that will upload a new report to the Report Server and
then tell it to use the datasource that is already there.
Plenty of examples in the doc, but specifically check out
CreateReport (to publish a report)
SetReportDataSources (to then set a datasource for that report)|||Very well (to all) then that is the way I will have to do it. I was kind of
hoping to be able to implement this 'referential' data source at design time
and just have that carry through during deployment, but it looks as if we
will have to hook it up after the fact.
In this case the developer is going to have to utilize 'their' data source,
which would be in a project and if its in the project I might as well let it
flow to the server. However, if I am going to do that, I might as well let
folks just standardize on imbedding the data source in the report itself and
if we should ever need to change it, just do so by parsing the XML in each
and every RDL.
"cmarinella@.gmail.com" wrote:
> You can certainly share a datasource by using the web API. You can
> write a script that will upload a new report to the Report Server and
> then tell it to use the datasource that is already there.
> Plenty of examples in the doc, but specifically check out
> CreateReport (to publish a report)
> SetReportDataSources (to then set a datasource for that report)
>