November 16, 2007 at 4:10 pm
I have reports on our SSRS server that use a data source with a path like /CustomDatasources/OurDataSource. I would like to set this DS up on my dev workstation so that I don't have to redefine the DataSource when I want to make report changes.
But I'm not sure what BIDS considers to be the root node folder, so I'm not sure where to locate the rds file. I've tried some trial & error locations but haven't stumbled it yet. Does anyone know where this would be?
November 17, 2007 at 10:18 am
In BIDS, you can set the Datasource path for deployment on the project property pages: Right-click on Project Name --> Properties. The TargetDataSource folder specifies the Full Qualified path for the reports (i.e., relative to Home Path).
If you want to replicate the PROD path in non-Prod, simply set that here.
Did I understand your question properly?
November 17, 2007 at 10:42 am
Scott,
Thanks for your reply; but that's not quite what I'm after.
We have a vendor supplied app that is built on top of SSRS to assist users in designing SSRS reports for their SQL DB. It always uses the same DataSource that is present on the prod SQL server. The datasource is located in a subfolder of the root node on the server.
There are occasions where something must be done to an existing report that is outside the capabilities of their custom report designer. I will export the RDL to BIDS on my dev machine. However BIDS always complains because the Data Source as it exists in the RDL does not exist on my workstation. I would like to place the data source file on my workstation so BIDS can find it - but I'm not sure how the root node on the server translates to a physical directory on my dev box. I'm not running SQL or IIS on my dev machine, so my question is - when you use the BIDS Dataset or Preview tabs, what would it consider to be the root directory, so I can place an rds file in the subfolder off of that root to match what is in the RDL file?
I'm not really deploying the report on my dev box; I just want to work with it from within the BIDS environment without messing with the DataSource definition.
November 19, 2007 at 6:39 pm
Thanks for the explanation. I think this will work for you:
1) In BIDS, add the RDL for your production report into a new or existing Report Project.
2) Create a new datasource in BIDS with the same name as the production datasource. BIDS will create the rds file in the physical directory associated with the Report Project. Alternatively, if you already have an rds file, you can simply right-click on Shared Data Srouces and add the file as an existing item. BIDS will take the source file from whereever it's physically located and copy it to the Project directory.
At this point, you can manipulate the datasource in BIDS as desired without impacting production.
BTW if you don't mind my asking, what is the 3rd party app you are using to manipulate the RDL? Is this intended as a user-driven report designer that doesn't require BIDS to create the report?
Hope this helps,
Scott
November 20, 2007 at 9:20 am
What you're suggesting is pretty much what I do now... I put a Data Source with the same name in the project directory. But since the rdl from the server contains a path relative to the root node like, /CustomDatasources/Mydatasource, I still have to go into the rdl code and strip out the /CustomDatasources/ path so that BIDS can find the Mydatasource.rds in the project directory. Then when I deploy, I have to add the /CustomDatasources/ path back in
I was hoping I could create a CustomDatasources folder somewhere that BIDS would find it and put a copy of the Mydatasource.rds in it. That way I could do this one time and not have to create another rds if I create a new project. Maybe this isn't possible in BIDS? Could be that the project folder is the only place BIDS can look for a data source?
As to the report designer. It's not a generic application. It's an app developed by Metavante, our banking system provider, that is tightly integrated with their database schema. Their db contains hundreds of tables and something around 30,000 fields. The report designer provides metadata that helps users locate the fields, perform the necessary joins, select criteria, etc. It allows mere mortals to compose reports and probably addresses 90% of the desired reports. It's the 10% that I have to pull into BIDS and tweak. For example, it can't handle self-joined tables.
Thanks,
Ed
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply