I'm creating cubes (xml schemas) via schema-workbench or ivy schema editor.
When I'm publishing it, I would like to know where the schemas (mondrian.xml files) are actually saved,What is the location of these files?
Thanks,
Which version of Pentaho BA server are you using? Pre or Post 5.0?
Pre 5.0: you choose the file path when publishing. The path is under you ${BISERVER}/pentaho-solutions.
5.0 and beyond: there's no physical file, it's stored in Pentaho's Jackrabbit repository only.
If you create any Analysis in Mondrian 5.*, and you have a test server and prod server, don't export Mondrian schemas from one to another. For a mystical reason you won't be able to get rid of them later.
This was my case, when I started searching for the pentaho-solutions/system/olap/datasources.xml in order to delete the problematic mondrian scheme. This source just doesn't exist anymore.
All data is now saved with the help of Jackrabbit. Jackrabbit stores your Mondrian Schemas together with all other Reports and Analysis to the database (the path is given in the jackrabbit preference file). But in the database you can only see their IDs. So there is no chance to get rid of one object - you leave everything or delete everything by truncating the table. The main problem is, that in the same table are saved not only schemas, but also all other reports, which you have downloaded to the server.
I am using MVC4 (the same applied while using MVC3). I somehow cannot open the App_Data folder. The data is there (the application can read it). But there is no way to collapse the folder to view the tables.
Can anyone give me a hint? I am trying out the tutorials, and one of them requires me to delete a certain table in the folder.
To access the database itself you will need to use the server explorer.
Have a look at the following link, it should give you some pointers:
Connect to Database
Hope this helps
I have set up a wordpress site, installed a theme, imported the sample data xml file, and did a sqldump of the database after completing these steps. I have a script that will automate the creation of the wordpress directory and database for a new site. I would like to add restoring the new database with the dump file. I have been able to do this but the links to wp-admin and wp-login point to the old site's directory instead of the new one. Any idea of why this may be and what can be done to avoid this?
I found the problem. The sql dump simply had all the data including the absolute links that were generated. So I used perl to search for the strings I needed to update in the sql dump before I put the data into the new database. Thanks.
Right now I have a project called reports with several reports. In solution explorer it looks like this:
Shared Data Sources
-- DEV
Reports
-- Report1
-- Report2
-- Report3
I want to make it look like this and have the same structure carry over to the report manager website when I click deploy.
Shared Data Sources
-- DEV
Folder A
-- Report1
Folder B
-- Report2
-- Report3
Anyone know how to do this?
I'm using SSRS 2005 - I think this part of it works in the same way as 2008.
As far as I can tell, you can't have folders within projects, but you can have multiple projects within a solution.
To create a new folder, right-click on the solution in the Solution Explorer and select Add>New Project...
Type in your new Project Name (eg. MyProject), and select Report Server Project from the list of Visual Studio installed templates. Click on OK, and your new Project should appear at the end of the list of projects in the Solution Explorer.
(There are other ways of setting up a new Reports project, but this seems to be the quickest.)
If you now right-click on your new Report Project and select Properties, you can see the TargetReportFolder, which will default to your new Project Name (eg. MyProject). When you deploy reports from SSRS, they are deployed to this location. (You can change the location, if you wish - I find it easier to keep track of what's going where by using the Project name.)
You will need to copy any data sources to be used in each project, into the data sources folder of all projects that use that data source. By default, OverwriteDataSources is set to false, so when you deploy a new report, it will use the data source already deployed to the Report Manager environment.
So to get the Report Manager structure that you want to see:
Create Projects called Folder A and Folder B
Move/copy Report1 into the Reports folder in Project Folder A
Move/copy Report2 and Report3 into the Reports folder in Project Folder B
Move/copy data source DEV into the Shared Data Sources folders in Projects Folder A and Folder B
Deploy your reports
Don't forget to check your changes into source control.
The way do it is similar to other posters, I have one solution with multiple projects (each project is named and put into the same folder name that I want it deployed under).
Then I rigged up a script in RS which:
- Creates a single data source used by all reports, in my case
- Loops through all directories in the solution folder
-- Creates the same folder name on the RS server
-- Deploys all files in this directory to that folder on the RS server
-- Uses rs.SetItemDataSources on each report to redirect it to my main data source
And that's basically it.
Caveats are you sometimes get files uploaded you didn't want to (like deleted reports with the .RDLs still hanging around). But you can script all around that, or just blow it away in RS and re-upload again.
Doing this, I have one script but can deploy a structure under numerous different parent folders, each with different data sources, and have all the reports in a folder drawing data from a different database. This lets me run 1x RS instance but have development, testing, training, etc areas.
We manage this with Linked Reports in SSRS. We deploy reports to a Report Distribution folder, hidden from users, then create Linked Reports in the Reporting Services web UI (an option in the Manage section for each report). You can create the Linked Report in any folder, so you can build the folder structure you want and put the linked reports in the appropriate place.
You can deploy everything to the single distrib folder from VS, and the linked reports are updated. This solves the sub-report and DataSource issues since all reports 'run from' the distrib folder. There's obviously a lot of setup up front, and creating a new environment is a hassle - It happens so infrequently that we haven't tried to automate it.
I have a BI project going in SSRS2008 with roughly 80 reports - and this is my experience with deploying reports into folders. This is my first foray into developing in Reporting Services, so any gurus please smack me if I'm out to lunch.
Initially, I used folders in source control to separate smaller reports by department to help keep me organized. That worked fine while I was initially developing my reports, however the first time I deployed the project to the report server the structure was completely flattened - so I gave up on using a folder structure to organize.
As far as I'm aware the only way you can create a folder structure in SSRS is to use the Report Manager UI and create folders on the Report Server. I'm assuming from there you would modify the path in the report properties in Visual Studio. Either that or you have to define the path when you first set up the report. I haven't tested this so YMMV.
So in conclusion: It is not possible to create the folders in BIDS and deploy your reports into folders utilizing the IDE. I hope this is addressed in 2008R2 because it's kind of a pain having all those reports thrown together in the Solution Explorer.
You can have the files in separate folders on the disk/source control however they list flat and sorted alphabetically in Visual Studio.
I cannot see a user interface to manage the above thing but if you edit the project file (single project file of a VS solution) you can specify the FullPath XML tag of each report file.
I created a report server type project and had no option to add another project. Instead I edited the SLN file and added my other projects. The first part of the SLN file then looked like this in the end to access my 2 projects in sub folders to the SLN file
Microsoft Visual Studio Solution File, Format Version 10.00
Visual Studio 2008
Project("{F14B399A-7131-4C87-9E4B-1186C45EF12D}") = "RestOfWorld", "RestOfWorld\RestOfWorld.rptproj", "{D24D5EEA-88A4-4375-802B-7CA877202787}"
EndProject
Project("{F14B399A-7131-4C87-9E4B-1186C45EF12D}") = "NorthAmerica", "NorthAmerica\NorthAmerica.rptproj", "{C64A3BDC-F526-4037-AD48-31799BECC3AD}"
EndProject
Global
#skiwii is correct, with VS 2013 Community edition and SQL Data Tools -- Business Intelligence, you do not see the Solution node at the top of the tree in VS Solution Explorer, and you do have to hack the .SLN file to expose it.
Start with the desired master .sln and one .rptproj file in your source tree. call that 'parent'.
Create a brand new, empty Report Services .rptproj file in a new subfolder (under the folder containing the .sln). e.g, project is 'child1'. VS will also give you a child1.sln file in that folder.
Close all VS windows.
With your favorite text editor (teco!)
open child1.sln.
Copy the 2 lines at the top; Project... and EndProject
Open parent1.sln
Paste those lines under the existing Project / EndProject.
Now open parent1.sln in VS. You will magically see the Solution node at the top of Solution Explorer window.
If you have been very lucky, you will also see a second project called child1. But if not, no problem. You can just right click on the solution and Add a new project of type Report Services.
I have a solution that contains multiple reporting projects (one per target deployment folder - I think this is the only way to achieve this effect, at least until I abandon Visual Studio for report deployment).
I want to specify my data source information "once and only once" for all these reports.
So far, I have created a separate reporting project that contains my shared data source. If I deploy things to a reporting server in the right order and offer sufficient prayers to appropriate gods, the reports seem to link up to the shared data source there and run (at least via the Report Manager in IE).
When I am developing a report, though, I can no longer "Preview" to try it out locally - I now must deploy it to a report server to try running it. This is a hassle.
Is my only recourse to add a whole bunch of copies of a data source (pointing at my development database), one in each project, set those not to deploy off my machine, and (probably) exclude them from source control?
A technique (dirty trick?) I am playing with now is to copy my data source (.rds) into each project, close Visual Studio, then in the underlying files/folders:
Delete the copied .rds from my report projects (leaving only the one copy in my Data Sources project)
In each report project's project file (Foo.rptproj), change the text of the Project.DataSources.ProjectItem.FullPath element from My Shared Data Source.rds to ..\Data Sources\My Shared Data Source.rds
This way all reporting projects reference the same underlying file on the filesystem, so they share a single data source definition, but each project also kind of has a "local" shared data source, so Visual Studio is kept happy.
Regarding source control: there is still only one copy of the .rds checked in, so we're not polluting the code base with lots of icky duplicates; the changes to the .rptproj files can be checked in, so we're not forcing developers into unnatural source-control gymnastics (selective partial commits etc.) to maintain a sane master copy.
Each reporting project will try to deploy this data source, though I've forbidden the overwriting of existing data sources on the server, so it's not too big a deal . . . and I suppose if I intended to overwrite the server's data source definition, it wouldn't really matter whether I overwrote it once or ten times with the same .rds.
Disclaimer: this is still an experiment. I don't have experience using this technique in practice yet, so I can't go so far as to actually recommend it.
Woody,
What we have tended to do is:
On the server have a folder called "DataSources", which is hidden from the users. In there will be all of the data sources.
For each reporting project in VS there will be a folder, also called "DataSources", but this time it will only contain the data source for this report.
As long as the folder structure is the same (i.e. report and data source have the same corresponding folder level on server and in VS) this seems to work for us.