I'm using Microsoft Reporting Services (SSRS) 2008 with an Extended Datareader/Dataset Provider (i.e. using a Datareader that I wrote myself and integrated it in SSRS). Everytime I have an update (i.e. copy the new binary files to the bin folder in SSRS), I manually have to restart the service.
I saw in IIS that the mechanism used in SSRS is similar to the IIS, but the IIS has a filewatcher and restarts automatically (or at least loads the new dlls/configs automatically) if files changed.
My question is if there is a mechanism (ideally integrated in SSRS already) that does the same for SQL Server Reporting Services 2008?
If not, what would be other options to handle this?
Seeing as no one is having a go at answering I'll have a stab. Could you not develop a small Windows service that monitors the directory for file updates using the FileSystemWatcher in .NET and then programatically restarts the SSRS service? You may be able to invoke a restart using WMI (check here). If not then you possibly could run a net stop and net start command, e.g.
net stop ReportServer$SQL2008
net start ReportServer$SQL2008
You may need to change the service name to match.
If you copying over binaries that are in use, then you'll need to stop the service before copying anyways. Which would mean more of a deployment script/app than a file watcher.
You can also use the ServiceController to stop and start services based on the name. So it wouldn't be that difficult to stop the service, push the new binaries and then start the service back up.
Here is an example for the service stopping and stopping.
Related
I have an Access DB app that exports a table (to XLS) then FTPs to our FTP server over our VPN. This routine has been working for several years, until ~yesterday. I am not sure what could have changed to break this function.
This is not really an Access DB issue as I see the same "Closed Connection" when manually attempting to FTP PUT at the Windows command line. Other users of the Access app (VPN and local) are not seeing this same issue.
I did receive a Win10 Security update this week - possible this affected my firewall settings?
Any suggestions where to begin? Googling suggests to portforward Port 20/21, but this seems to have no effect either.
Thank You!
Note 1: I do use WinSCP for passive transfers for another specific task to FTP to a 3rd party who requires passive transfers. Some of our users in India are unable to use this tool reliably, so I am hesitant to convert this basic function in my Access app as it works everywhere but my local machine.
Note 2: I attempted to add "QUOTE PASV" before a command line transfer with no effect. As I am reading, Windows FTP utility does not support Passive transfers
Note 3: FileZilla can see and transfer to the FTP server using "Plain FTP" mode. Interesting, but I really need this to work via command line without requiring a 3rd part app installation.
Note 4: I uninstalled the Win10 Security Update - No effect
I'm trying to deploy an SSRS report to a remote server (that is not on my network). I'm not sure how to do this. For a machine on my network, I would just change the TargetURL, but I'm guessing there should be somewhere that I can associate credentials to deploy to a remote server, but I'm not finding it.
I know this is an old post but if someone is wondering about the same question.
I am using vs2017 enterprise. So when you configure your remote url and folder name and everything is perfect to build your project, you hit F5 or deploy your project. Upon successful building vs will prompt you for your report servers credential. Then you do the usual and vs will do its own job. In a moment you will be able to access your report.
Just read about the permission requirements before you try it.
Hope it will help someone.
Thanks
I face a similar issue delivering reports to various servers (customers and dev,qa,staging and production.) In visual studio the best way to do it is start a new project for the new server and import the new reports into it. You end up with a new project for each server.
I found TFS / VS unwieldy and my workflow to manage it unfortunately is doing it manually, or using one of a few open source report uploading tools (there are powershell scripts to do it but I find the tools are more user friendly.)
Best thing to start with is doing it manually; which will sort your initial problem.
Save the file out of your report writer to disk.
In Internet Explorer log into the Report Manager of the remote server http(s)://remoteservername/reports and navigate to the folder you want. Then upload the report.
When its uploaded you may need to fix the connection to the database.
Once you get used to doing this you can use a tool like reportsync to easily and quickly move reports between servers.
We normally use Microsoft.ACE.OLEDB.12.0 to read and write from MS Access Databases. On a normal Server you can just install office or the AccessDatabaseEngine_x64.exe and this works fine.
Now we want to move our app to Azure (Preferably the Azure Websites and not WebRole or full VM). But there we obviously can't install the Access Drivers.
Is there another way to use Access on Azure? Maybe a 3rd party driver or something that can be run/installed with user privileges.
We looked at dotConnect, but as far as I understand, this still needs OLE DB.
Switching to Azure SQL is not an option, as Access is used as a "FileType" for a 3rd Party system that we use.
Specifically for a cloud service, you can do the following:
Create a cloud service that wraps your core project/site.
Include the MDB in the project that is wrapped from (1). Many ways to do that.
Include any executables or scripts you want to be deployed as well. You can add them to a Visual Studio project and set their Build Action to Content.
In the project that is wrapped, include a WebRole.cs file and implement RoleEntryPoint and specifically implement public override bool OnStart(). This will allow you to run scripts, move files on the file system etc.
The nice thing about using WebRole.cs to run your initialization code is that when Azure reimages your cloud service, the code will always run and get the machine back to a known state.
So my problem is that on an already working instance of SQL Server 2008R2, a former colleague of mine installed a new instance, apparently with the same name and leaving us now with an empty Report Manager. The URL for the old one still works, but it only shows me the file structure for the old Report Manager.
Is there a way to somehow extract the old RDLs (considering it has no graphical interface anymore) so that I may load them to the new one? Or alternatively, set the ReportServer service to use the old instance in order to download the RDL files?
Thanks in advance.
I can think about a couple of options:
Download through Report Builder
It sounds like the old ReportServer URL is available? That's something, at least.
One option that might have the least impact is connecting to the old ReportServer through Report Builder, opening the RDL files then saving them to the location of your choice.
Connect to the ReportServer:
Navigate and open the file you need.
Click Save As to save the RDL as required.
Start/restart different instances
Based on your description, it sounds like both instances are trying to register the same URL.
If possible, I would stop both instances, then restart the old instance which has the RDL files you want.
Hopefully this will allow the old instance to register its URLs successfully and allow you to connect to the old Report Manager URL and download the RDL files.
You can check the different URLs each instance is using through the Reporting Services Configuration Manager application:
In my development environment, every time I reboot windows (which must be done at least daily for me), all of my Shared SSRS Datasources lose their credentials.
Currently I have them set up to log into the database using a fixed credential, but on reboot all the datasources pop over to using no credentials. Granted, it's only in the dev environment, and I can just check out/update the datasource/check back in and it will work fine... until I reboot again.
FYI, I've been using these Shared Datasources for at least 2 years and no problems, but in the last month or so, it's been a recurring daily problem.
Help?
I'm assuming you are talking about the Shared Data Sources in a Report Server project in Visual Studio, as opposed to a Data Source created directly on Reporting Services. The latter, the data is stored all in the ReportServer database that was specified when setting up SSRS.
Now, as for the .rds file used in Visual Studio, if you open the file up in a text editor, notice that the username and password is not stored in the file. It is actually stored in the .rptproj.user file. So, check that someone didn't remove the .user file from source control (.user files shouldn't be in source control, but in your case...).
This is scenario is testable by entering your credentials, saving all files, and exiting Visual Studio. Find and delete the .rptproj.user file, and open your Report Server project up again and see the credentials gone!
A work around is add the "User ID=user;Password=pass" as part of the Connection String. When the .rds is opened up, the Connection String won't show this portion, but the Credentials tab should have the right values.
Could this be related to the boot order of services on your machine.
Just a guess: Maybe there is new functionality in SP3 that checks if the connection credentials are valid. If they are not valid they are cleared.
The problem would then happen if this check is done before SQL server has had time to start. This would explain why they are cleared when the machine restarts.
I have recently experienced the same problem, but I can't connect it to a reboot. It seemed to happen when I checked the solution from source control - we use Team Foundation Server. After disabling the service account a bazillion times, it somehow healed itself and began behaving. I found this post and checked my project folder for the rptproj.user file that benson mentioned, and it has a modified date of the day I had problems, but a create date of close to what I can remember as having created the project, so I will pay attention to this in the future.
Did anyone come up with anything new on this issue?
I realize you may have read this already, but something here could help? http://msdn.microsoft.com/en-us/library/ms159846.aspx
I would pay attention to how the SSRS was installed and also what accounts the servies run as, as well as an domain logon policies.