I recently started learning SSRS; I created a data source over SSRS web-portal; I am wandering whether such a data source can be accessed from /by Report Designer to create report and data sets.
Would anyone please help me understand the scope of such data source created in SSRS web-portal.
Thank you for giving your valuable time.
Generally you will create your shared data sources in Visual Studio/Report Designer and then publish them to the server. The end results is that you will have a data source available on the server (as it sounds like you have now).
By default data sources are not overwritten when you deploy reports, the idea is that you can have a data source on your development machine and as long as it has the exact same name on the server, when you deploy your report, it will look for the data source of the same name.
As it sounds like you created the data source directly from the web portal, you will have to recreate it on your development machine with the same name, when you deploy the report it will use the version on the server.
This also means that you can have a data source on your development machine, called dsSales for example and it might point to myTestServer\myDatabase and on the production server you could have a data source with the same name, pointing to myProductionServer\myDatabase (assuming the same tables etc exist on both) then you can test with data from the test server and when you deploy it will connect using the data source that connects to the production server.
I hope that clears it up a little.
Related
I have an access database that uses data pulled from an API, this data export is conducted hourly.
I would like the access database to automatically run an update module (which imports the exported data and cleans it up), based on the same schedule the API exports my data, so Access will be current at all times.
The database I designed is used company wide. The accde and backend are both located on a windows 2008 server.
I just wanted suggestions on the best way to automate this, without the need of human intervention, preferably nor my local machine.
From rough research (accompanied by my own ignorance and stupidity) I’m assuming I need to setup a task scheduler on the server to launch access and run the module on open if FOS username is the local machines user (administrator).
I highly welcome any feedback as again, I just taught myself access these past two months and am horribly unknowledgeable on the implementation side.
Data Source missing
Data Source,tried to save
The issue is when I hit save to connect to a shared data source it doesn't save. When I run the report and get the below error. Then go back and the shared data source is gone. I can see that the link and extensions are null. Please help :-)
The report server cannot process the report or shared dataset. The shared data source 'SSAS_PRN' for the report server is not valid.
Problem = There was many different versions of the same data sets.
The solution was to wipe out all of them, then start fresh.
Then in Report builder.
Under the data Sources Properties.
Browse to the new version.
Hit save.
The report now works on the server.
For my company there is a report that ends up in an access database format (.accdb) when it gets to my department. We want to deploy an SSRS with this information. While I was able to do it in Visual Studio the database manager questioned whether this can actually be deployed and work in the server environment. Can this this be achieved?
Are you talking about an Access report, or data inside of Access?
SQL server reports are not built in Access and have absolute nothing to do with Access. The only issue would be then since the report cannot be built in Access, then why attempt to have SQL server open an accDB file for the data source? You would be much better off to simply have Access transfer the table data to SQL server and then continue to use the reports built in SQL server.
So a report in Access has ZERO relationship to SQL server reports. As such, the reports in Access are of no use and if your plan is to use SSRS, then the reports have to be built in SSRS.
It is possible to place an Access accDB data file on the server and have SQL server connect such data, but it generally does not allow or work well with multiple users.
Keep in mind, the reverse is certainly possible and often recommended. You place and keep all data on SQL server tables. You then link the Access application to SQL server. In this setup then the data ALWAYS resides on SQL server, but the reports are in Access. And the general forms etc. built in Access will save + send their data to SQL server (and this works without having to write code).
The above thus suggests that the Access application with the reports has to be distributed to users that need such reports. And such users will thus all share only ONE copy of the data since such data resides on SQL server. And this setup would also allow one to create reports in SSRS without having to upload any kind of data, since the live operating data from the Access application always resides on SQL server.
So in summary:
Access reports are Access reports, just like FoxPro reports are FoxPro reports, and FileMaker reports are FileMaker reports. As such, these reports cannot be used, viewed, or utilized by SQL server in anyway.
However, the reverse is not only possible, but is a common solution. Thus the Access (front end) is linked to SQL server and the data tables for forms, code, reports etc. for the Access application now resides on SQL server.
If you place the actual accDB data file from Access ON the SQL server, then SQL server can read the data, but any code, forms, reports etc. from Access cannot be used by SQL server. So a report in Access is of ZERO use to SSRS.
So if SSRS is a goal, then anything built in Access from a user interface point of view cannot be used. SSRS thus can only consume the data in tables.
Since SSRS can ONLY consume data from Access (and nothing else), then a far better solution in place of moving up a accDB file to the server is to simply push up the data from Access tables to a SQL server tables. And if such a data transfer is to occur often, then likely better is to ALWAYS keep the tables and data in SQL server, and have the Access front end part “link” to the data on SQL server. Access reports, forms and even VBA code will in most cases run as before, but the live data always resides in SQL server. You thus eliminate all the dance and song of attempting to transfer data between two systems. The SQL server data is thus always “live” and update to date, and only ONE copy of the table data EVER exists.
Most Access applications and reports and forms can work with very few (if any) modifications when you place the data tables on SQL server, and have the front end Access part “link” to SQL server.
Since a given specialized report in SSRS is going to require a pre-determined and non changing table structure, then the most prudent solution would be to have Access link to and use the data from SQL server tables (not the other way around).
So Access reports can ONLY be used by those with Access (or the free runtime) installed on each client desktop computer. Such Access reports have to be 100% re-built if your goal is to have such reports be used with SSRS.
Using:
SSRS Report Server 10.50.1600.1
BIDS Visual Studio 9.0.30729.4462 (from remote client on same domain and network; not local on SSRS server)
I'd like to be able to add existing shared data sources and shared datasets that live on my report server to my BIDS project on my local workstation.
I know I can create a shared resource from a BIDS instance, and deploy it to the SSRS server. I can also do the same via Report Builder 3.0; deploy or publish from either application, then navigate to the report server URL (https://SSRSServer.mydomain.com/reportserver), download the resource(s) to my machine, add them as a Shared resource, and then redeploy as appropriate...but that's a bit convoluted.
What I'd like to do is add a shared data source (or set) in BIDS the same way that I can in Report Builder 3.0. In RB, I can navigate to the report server URL (using WebDAV, I'm assuming), and pick the rsds file I need, however, from BIDS, I'm only able to browse UNC and local paths (URL+DAVWWWRoot doesn't work, and neither does manually adding a data connection string).
I feel like I'm overlooking something obvious, but I can't find anything on the subject, and I've been racking my brain for too long this morning...
In short: is there anyway to browse my report server resources from BIDS 2008, in the same fashion as Report Builder 3.0 with the intention of adding existing datasets and data sources (please see screenshots for reference)?
Image taken from adding a shared data source from Report Builder 3.0
I'm sad to tell you but there is not.
You only can save those objects ,local by downloading them and then adding to the project explicitly.
I checked if there is a way to paste multiple datasets/datasources into your project file but it is also not possible, looks like it is encrypted in the state string of the project file.
I've inherited a live SSRS server and have been asked to amend a lot of reports that are on there.
Is there a quick way I can "export" all of the reports/data sources to a local instance so I can develop against it using BIDS?
e.g. Can I copy the ReportServer database from Production?
What else would I need to do?
I'd like to be able to have a Development copy of everything, with DataSources pointing to copies of the production databases but with the same names. Therefore I could re-write the report and re-define any SP's required locally, and then just deploy the new RDL to the server along with the ALTER SP scripts.
Is that possible or even sensible!?
Personally, with the volume you mentioned in the comments (30 RDL's and 3 databases) I wouldn't recommend some automated cloning of the entire Reporting setup from production to local. Instead, I'd suggest the following:
Reports
Go to the web front-end for your reportserver (typically http://yourserver/reports). Find each report, open it, and on the Properties tab click the Edit button. This button does not do what you might expect (edit the report inside the browser), but instead offers you a download of the RDL file. Save all the RDL files in one folder on disk.
With 30 reports manually downloading the reports may take you maybe an hour, max. This will probably beat most automated approaches. And since you should only need to do this step once...
Databases
It's not entirely clear from the question, but if you only have production databases and no DTAP setup yet, now may be a good time to start with that. You could host clones of the 3 production databases on a test server or possibly on your dev environment. Note that the schema's important here (should be the same as production), the data doesn't have to be entirely up to date.
Alternatively you can skip this bit and develop your reports against the production databases, assuming you can create connections from your dev machine to the production databases. Up to you.
Visual Studio / BIDS
This bit has a few parts to it:
Create a new reports project and solution in Visual Studio.
Add the existing RDL files you've downloaded earlier.
Depending on how the reports were set up, you may need to add shared data sources in your project, to get your reports up and running.
After all this, you should be able to preview your reports from Visual Studio (either with data coming from the "cloned" databases, or directly from production).
At this point you should also be able to safely make changes and preview/test them before deploying them.
Be sure to add the solution, reports, etc. to your version control system of choice.
Deployment
Once you've made changes you want to deploy to the reportserver, you have two basic options:
Deploy them using BIDS (see also the deployment properties MSDN page)
Go back to the web front-end, find the report, open the Properties tab again, click the Update button. This allows you to re-upload the RDL file with the changes you've made.
From now on you can just rinse and repeat on making updates and deploying the reports. No need for cloning/exporting the entire SSRS instance to keep things in sync.