Another SSRS question here:
We have a development, a QA, a Prod-Backup and a Production SSRS set of servers.
On our production and prod-backup, SSRS will go to sleep if not used for a period of time.
This does not occur on our development or QA server.
In the corporate environment we're in, we don't have physical (or even remote login) access to these machines, and have to work with a team of remote administrators to configure our SSRS application.
We have asked that they fix, if possible, this issue. So far, they haven't been able to identify the issue, and I would like to know if any of my peers know the answer to this question. Thanks.
For anybody using the integrated webserver that is built into SQL Reporting Services (and hence IIS may not even be installed on the box), the setting to control this actually lives in:
C:\Program Files\Microsoft SQL Server\
MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\rsreportserver.config
Your directory may be different; version 10_50 maps to SQL 2008 R2.
You'll be looking for the setting called RecycleTime.
Default is 720 (12 hours). Setting it to 0 will disable.
In IIS, check the settings on the application pool that SSRS is running in. On the properties pane->Performance tab you can set the amount of time the worker process needs to be idle for before it shuts down. You can also disable this entirely.
I vaguely recall having problems with SSRS on one machine when we changed the "Enable HTTP Keep-Alives" setting in IIS. Try toggling that checkbox (I don't remember whether it was checked or unchecked when it caused us problems).
Related
As a .NET Desktop developer, I have a lot of experience working with various databases that are already up and running; but I'm not a DBA. I'm currently working at a company where I am ther only software guy here to build them software from scratch -- their previous enterprise-level solution was an Access database with macros and a couple forms built it. So, I basically have no one else to go to.
With that preface, how the heck do I get a database -- ANY DATABASE!!! -- added to my VS solution? I've been beating my head against this for almost 6 hours and have made zero headway. At this point, I'm ready to say, "Screw MS databases!" and start looking at MySQL or PostgreSQL or something.
The desktop application I'm developing has to work whether there is an internet connection or not, so I need a local database that installs with ClickOnce. From what I've found so far:
SQL Server [Express] 2016+ requires Windows 8 or later (a non-starter since 95% our customers are still running Windows 7)
SQL Server Compact is being deprecated and won't work past VS2013
I think LocalDB is what replaces Compact in 2016+ (?)
Okay, so I started with this tutorial:https: //learn.microsoft.com/en-us/visualstudio/data-tools/create-a-sql-database-by-using-a-designer However, trying to add a "Service-based Database" just gives me this error once: "The 'DBProviderFactories' section can only appear once per config file." I try again and get this error repeatedly: "Unable to find DbProviderFactory for type System.Data.SqlClientConnection" I've Googled both errors and all the answers that I've been able to find pertain to VS2010 or earlier and their solutions are either not applicable or don't work.
Next, I tried this tutorial: https://msdn.microsoft.com/en-us/library/aa983322.aspx I've tried adding new data connections through the "Server Explorer" panel. I don't see "[*] Compact" as an option. When I try "Microsoft SQL Server Database File", I just get the error: Unable to find the requested .Net Framework Data Provider. It may not be installed."
I've even tried adding data sources through the "Data Sources" panel; that doesn't work either.
I've installed the "Data storage and development" addon from the Visual Studio Installer, several versions of SQL Server 2014, SQL Server Compact 4.0, and maybe a few other executables from Microsoft's website.
Nothing works.
Help...
I think I just found it!
Evidently, there are "machine.config" files on your computer. Search for them all, and make sure that there is only a single tag for "DbProviderFactories". I can add a database object now. Hopefully, this puts me in business...
https://social.msdn.microsoft.com/Forums/vstudio/en-US/7b4f353b-77fd-427c-976b-5968abc88c13/visual-studio-2010-unable-to-find-the-requested-net-framework-data-provider-for-sql?forum=vseditor
If what you are saying is that you are writing a browser based application - then one would migrate the tables to SQL Server (Express) or even MySQL - it really doesn't matter. Then write a new web app. The existing Access app would serve as a model for seeing features & screen layout but is otherwise not portable.
On the other hand, if you are re-writing a Windows application; then the decision is whether the payload requires a server solution or if one can stay at the PC level. If the payload is suitable for PC then a re-write using either Visual Studio or Access again.
Access is a front end db - the tables in the back end whether they be stored in SQL Server or an Access file are entirely passive. All the processing is done by the user's PC. If the payload allows that then this is the lowest cost re-write option.
If you've outgrown a PC level payload - then one must develop a back end database feature set with a more passive front end.
Okay all, the subject is a pretty poor one, but I'm not sure how else to put it. I have Server 2012 with a bunch of jobs, all owned by sa. They all worked fine ever since I began working here in January 2016, but we recently made major changes to our servers. Currently, we have a few servers off the domain, and set up together as a workgroup. They're clones of what we were running before the shakeup, so include all the data/logins. The main difference is that they can't talk to our Active Directory anymore.
Back to SQL Server. Some of the jobs on the server have to read from and write to an FTP folder on one of the servers which is in the same workgroup. That is, both the 2012 server and the FTP server are on the same workgroup, so should talk to each other with no problem. However, some of the jobs keep failing because of logon errors when trying to connect to the FTP server. I'm not using FTP, but rather network locations, like \\1.2.3.4\ftp\folder\file.txt in my job code. This worked perfectly until the servers moved. Skipping the long and confusing reasons why, suffice it to say that this server won't be back in contact with Active Directory for some time. Indeed, letting it be so can't happen until we can shut down its on-domain counterpart. However, we can't do that until I get this working sans domain contact. Again, long story behind that catch-22.
My questions after dealing with all this are:
If the job in question is owned by sa, why do the logs show logon attempts by nt access\network authority?
How/where can I change the username/password the 2012 server is using to talk to the FTP server?
Is there a way I could access the FTP server, given the workgroup setup in place, that's easier than what I'm trying to do now? Sharing settings on the FTP folder, for instance?
Thanks for any explanations anyone can offer. I'm thoroughly confused about permissions, accounts, credentials, and remote access and have no idea where to turn, having googled all of this exhaustively.
I have not worked with servers that were not domain joined, but I have had similar issues when using SSIS accross sub-domains (see original answer below for more detail). I would look at the setup of sql server and see what service accounts were used for the sql database service and the sql agent service (check out https://msdn.microsoft.com/en-us/library/ms143504.aspx). ALso, make sure that the server accounts have permissions to the file system locations (you likely already did that, but just in case).
Original Answer for SSIS Situations ( I misunderstood that the asker wasn't using SSIS):
You might need to set up a proxy to control what account is used. There is a section on proxies in this article that you might find helpful. I suggest reading the entire article, it might shed some light.
https://www.simple-talk.com/sql/database-administration/setting-up-your-sql-server-agent-correctly/
I recently moved several reports over to a new server. Everything works fine displaying tables and data, but charts are not displaying properly. It looks like the image is not rendering properly. My initial thought was that this was a permissions issue, specifically that the service account used to run SSRS needed permissions to a certain folder on the server that is used to generated chart images, but I can not find anything about this in searching for a solution.
This happens with old reports that display fine on the original server and new reports I try making on the new server.
EDIT: SSRS logs are showing a generic error in GDI+. Looks like this may be the issue, especially since this is running on a virtual server:
http://social.technet.microsoft.com/Forums/en-US/37ed20b2-99bc-4e36-a14b-c9f8cc297be3/ssrs-2012-reports-with-charts-generic-error-in-gdi-?forum=sqlreportingservices
I am curious about a point made in this question:
2) Ensure write permissions on the "folder to which SSRS caches the charts"
Well, firstly, I have not found a single article on the net as to
where this folder is; however, I tested this locally on the server
while logged in as Administrator with full privileges. This doesn't
seem to apply to my situation either.
Does anyone know about this folder? I would imagine that running while logged in as an admin would not mean anything since the service account running SSRS would need the correct privileges.
Someone had a similar problem and the solution was to repair the SQL Server installation. I know it is quite long to run but it might be worth a try.
Equivalent topic in SO
You can try restarting the report server. That worked in my case with Sharepoint and SQL Server 2012. Or repair the SQL server installation on the server as some posts suggest.
SSRS 2012 Charts Not Rendering
I had the same issue when deploying a new report locally.
I restarted my Report Server service and the reports rendered fine.
Our local IT has our My Documents folder on a network path. This causes a problem from MSQL Server management studio as it saves it auto recovery information every 10 min it will lock up as its doing its save.
I found where VS2008 saved its setting but I can not find out how to change it out of My Documents for this. Does anyone know where that setting is located?
Unfortunately, at least for VS2005 and VS2008 (and I think for VS2010, but I haven't checked there), this cannot be changed from the system's "My Documents" folder. This is terribly annoying, I agree, as we have our My Docs folder set to a network share. When we're on VPN, the network connection is very slow, so the auto-recovery feature isn't instantaneous and blocks the UI.
I found this feedback on Microsoft Connect that indicates the inability to change the setting: Saving Auto Recover Information in Visual Studio 2008 SP1
There are few "alternatives." You could, of course, turn off Auto-Recovery, but that's not generally recommended. What I've ultimately decided to do is simply increase the time interval between auto-saves. This is found under Tools\Options\Environment\AutoRecover (in VS2008), which is the same place you would go to turn it on/off.
Of course, in SQL Server Management Studio, there is no Environment\AutoRecover section in the options. However, if we remember that SSMS uses the Visual Studio core (and we're comfortable with a bit of registry hacking), we can adjust the time interval for SSMS, as well.
VS uses a REG_DWORD value named "AutoRecover Save Interval" to store the number of minutes between auto-saves. Just add that value to the following key in the registry (this is for SSMS2008). I set mine to 60 because I don't usually do much super-critical work in SSMS, but you can set it to a value that suites you.
HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\100\Tools\Shell\General\AutoRecover
I realize this isn't really a solution to the original issue, but I think it's at least a viable alternative.
As a follow up, with later versions of SSMS Microsoft did add Auto Recover settings in Tools > Options > Environment > AutoRecover.
I found recovered files on my machine at: C:\Users<MyUserName>\Documents\Visual Studio 2017\Backup Files\Solution1
Vista just finished one of its many updates. After restarting my computer I try connecting to SqlServer2008 instance with Sql Server Management Studio and I get this error:
Error connecting to '...\MSSQLSERVER2008'.
Additional information:
Login failed for user '...'. Reason: Server is in script upgrade mode. Only administrator can connect at this time. (Microsoft SQL Server, Error: 18401).
Pressing help gets me to an internet page saying there's no additional information.
Thx Vista & Updates. Anyone an idea because on the internet I can't find anything about this issue.
It appears This Guy was having the same problems as you and his only suggestion was to wait a few minutes before trying to log in again.
I have yet to see any type of Microsoft documentation about this, nor have I seen any forum posts which came to any sort of resolution concerning the same problem.
Check your event viewer. I had the same problem and found that (in my case) it was looking for a directory that didn't exist to perform an upgrade script. NO hint that there was any sort of problem in the dialog, but the event viewer showed clearly what the problem was.
jim
I had the same problem. Waiting until update was done did not help. Solution was, (after checking Windows eventlog) to set the folder rights. SQL-Express had no rights on the database folder, why ever. Something has mixed up the rights during the upgrade from WinXP to Win 7. That was it.
Adding a comment to this page since this is the top Google result for "script upgrade mode". It seems that a number of things can cause a SQL Server DB to go into this mode. In our shop we've run into these two cases in the past months:
Log shipping - Can't recall at what point of the process exactly the DB went into this mode, iirc it was when bringing it back up. The solution was just to wait it out.
Hard drive full - The DB went into this mode when it ran out of space. We're currently clearing up the drive, will come back with an update if waking it up turns out to be challenging.
Update: After freeing up disk space, it was a simple matter of setting the DB "Offline" and then "Online" to bring it back up.
We had the same issue, but needed to know what was going on in the background.
The db's were put into recovery mode, hence they had to recover. To assist we went to the SQL Server error log located where the system files (normally master, model, msdb...) are located, but under the log folder. In the ERRORLOG, we did a find on the word recovery and could watch the db's percentage recovered. Everything recovered normally, but it was much longer than expected.
The Reason for this is that the system reboot happens with important\necesssary softwares loaded and does all other operation later so that the booting happens faster.
Here in your case, the sql booting is happening as the start of SQL is not needed for system to start. I hope you are aware of DAC account(Dedicated Administrator Connection, Link) who has seperate connectivity and has ability to resolve issues even the whole SQL server is not responing. The SQL server is asking you either to wait or open the SQL with DAC account and stop the SQL update.
Solutions:
1) Wait until backround update completes
2) Open SQL using DAC account and kill all running processes