When I try to access the SSRS Web Service URL (e.g http://SERVERNAME:1234/ReportServer/), it provides me with an Error 500. However, the Web Portal URL (http://SERVERNAME:1234/Reports/) works just fine. It even provides me with the UI for the SQL Server Reporting Services.
So far I've tried re-installing the SSRS, changing the ports, accounts and the database, all without any luck (the Reporting Services service is running). I am genuinely out of ideas and Microsoft's documentation is terrible regarding this particular issue as it suggested attempting to modify the NETWORK SERVICE account permissions, which can be done after adding one of the Windows features (which, I may add, can be done only on the Enterprise version of WIndows 10).
Has anyone had this issue or managed to find a workaround?
The instance of SSRS has two web applications, which are pretty independent. Normally they have such URLs:
http://ServerName/Reports
http://ServerName/ReportServer
In your case, seems first one configured and work correctly and the second one failing.
The reason of a failure can be found in log files that are in stored in a SSRS instance folder, for instance:
D:\SQLData\MSRS13.MSSQLSERVER\Reporting Services\LogFiles
This path can be different, depends what was chosen during the initial installation as the instance directory. It can be found by opening a task manager and discovering a file location of ReportingServicesService.exe:
Then, in the LogFiles directory open the most recent log file and check for messages with a category ERROR, like:
ERROR: Throwing Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: , Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Query execution failed for dataset 'RequestTypeList'. ---> System.Data.SqlClient.SqlException: Invalid object name 'dbo.FactHistoricTrend'.
Could not use view or function 'dbo.FactFlatSSRS_Trend' because of binding errors.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption, Boolean shouldCacheForAlwaysEncrypted)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at Microsoft.ReportingServices.DataExtensions.SqlCommandWrapperExtension.ExecuteReader(CommandBehavior behavior)
at Microsoft.ReportingServices.OnDemandProcessing.RuntimeLiveQueryExecutor.ExecuteReader(IJobContext jobContext, DataSourceErrorInspector errorInspector, String commandText)
--- End of inner exception stack trace ---;
In this way, you will know what is the reason of Error 500 of your ReportServer web service
While I will mark Alexander's post as the answer because it was a good indication on how to debug the issue, I will post that the actual issue were permissions - I had to provide the NETWORK SERVICE account with rwx permissions for the SSRS root folder (in my case, it was the E:\Program Files\Microsoft SQL Server Reporting Services; Properties -> Security -> Edit...).
A few years late, but still an issue with SSRS 2019.
Following on from TheDoomDestroyer's comment, giving the service account used for the SSRS service, in our case a domain account, full control on the SSRS folder worked. Restarted the SSRS service and then was able to get the ReportServer URL.
Another annoying MS omission when configuring the service that it doesn't do that itself.
Related
I have a strange problem where the JPA mapping is failing on converting to a timestamp, but the value it's using appears to be the entire row, not just one variable.
The error is:
java.sql.SQLException: Value '1988├╗ ├╗├╗├╗├╗├╗├╗0
07 1234567 wk├╗0├╗├╗├╗├╗├╗ ' can not be represented as java.sql.Timestamp
where the value seems to be the entire row, with most of the bad characters being nulls. Debug logging isn't giving me much at the moment, and I'm not sure whether it's an error in my mapping class, collation issues, or something else.
MySQL workbench reads all the information from the table correctly. Running mysql from the command outputs all the data correctly. Neither show any special characters anywhere.
A simplified version of my mapping class is:
#Entity
#Audited
#JsonIgnoreProperties({"hibernateLazyInitializer", "handler"})
public class PersonSundry {
#Id
#GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
#NotNull
#OneToOne(fetch=FetchType.LAZY)
#JoinColumn(name="person_id", unique=true)
private Person person;
#ManyToOne(fetch=FetchType.EAGER)
private Lookup1 lookup1;
#ManyToOne(fetch=FetchType.EAGER)
private Lookup2 lookup2;
#Lob
private String backgroundInfo;
private LocalDate dateOfSomething1;
private LocalDate dateOfSomething2;
private LocalDate dateOfSomething3;
// getters and setters
}
Has anyone come across this before? Any ideas where else to look?
EDIT: The root cause turned out to be a generic failed cast of 00-00-0000 to a timestamp, however I'm going to leave the question open to see if someone knows where the strange error message was given instead of an exact one.
Are you using MYSQL?
Please try using this type of connection string.
jdbc:mysql://yourserver:3306/yourdatabase?zeroDateTimeBehavior=convertToNull
Datetimes with all-zero components (0000-00-00 ...) — These values can not be represented reliably in Java. Connector/J 3.0.x always converted them to NULL when being read from a ResultSet.
Connector/J 3.1 throws an exception by default when these values are encountered as this is the most correct behavior according to the JDBC and SQL standards. This behavior can be modified using the zeroDateTimeBehavior configuration property. The allowable values are:
exception (the default), which throws an SQLException with an SQLState of S1009.
convertToNull, which returns NULL instead of the date.
round, which rounds the date to the nearest closest value which is 0001-01-01.
I'm getting an error from OrmLiteWriteCommandExtensions in my log, and I can't seem to find where this happens. I have no loss of data; when I have the logfactiory set to null, it breaks on no errors; I have set it to allow zero date, but that didn't help. I not sure how to debug this or get around it. It clogs up my logg with statements that I can't track.
This occurs on both linux and windows.
Doesn anyone have an idea how to get at this?
OrmLiteWriteCommandExtensions System.FormatException: String was not recognized as a valid DateTime.
at System.DateTimeParse.ParseExact(String s, String format, DateTimeFormatInfo dtfi, DateTimeStyles style)
at System.DateTime.ParseExact(String s, String format, IFormatProvider provider, DateTimeStyles style)
at ServiceStack.Text.Common.DateTimeSerializer.ParseShortestXsdDateTime(String dateTimeStr)
at ServiceStack.OrmLite.Converters.DateTimeConverter.FromDbValue(Type fieldType, Object value)
at ServiceStack.OrmLite.OrmLiteWriteCommandExtensions.PopulateWithSqlReader[T](T objWithProperties, IOrmLiteDialectProvider dialectProvider, IDataReader reader, Tuple`3[] indexCache, Object[] values)
UPDATE:
The logging occurs in the correct file set in the nlog config file, BUT for this exception only it does not conform to formatting in the layout set for NLOG (all other exceptions do!).
Layout string:
${longdate} ${machinename} ${logger} ${level} ${message} ${onexception:EXCEPTION OCCURRED:${exception:format=type,message,method:maxInnerExceptionLevel=5:innerFormat=shortType,message,method}}
UPDATE2 SOLVED:
So this was fun... Before I start to explain how I solved it I have to say that I have no idea why it writes in the correct log file, but ignore all formatting for logging errors - that be another dragon to slay for another time.
So the problem was that a varchar field in the mysql database had birthdate as string and the implicit conversion between DateTime in dotnet to string thre an error.
After changing the field to datetime in thet database the error went away.
Funny thing is that I hade to set minlevel to trace to get the error in context with its call to the database - but it still ignored all error formatting, had no stacktrace, no sql statement, and no line number associated with the error in the log.
So the problem was that a varchar field in the mysql database had birthdate as string and the implicit conversion between DateTime in dotnet to string thre an error.
After changing the field to datetime in thet database the error went away.
Funny thing is that I had to set minlevel to trace to get the error in context with its call to the database - but it still ignored all error formatting, had no stacktrace, no sql statement, and no line number associated with the error in the log.
Situation: working with legacy classic ASP code, attempting to move the codebase from an old server to a new one.
The code attempts to connect to a MySQL database on a Windows server using the MySQL ODBC 5.1 driver and the ADODB.Connection object.
Connection String = "Driver={MySQL ODBC 5.1 Driver};Server=dbserver;Database=dbname;Uid=username;Password=password;Option=3"
Query results are returned in ADODB.RecordSet objects.
When I try to access a field containing a standard MySQL Integer, I get this error:
Microsoft VBScript runtime error '800a01ca'
Variable uses an Automation type not supported in VBScript
If I manually convert the field using cLng() then the error is eliminated and the correct value is returned. However, there is too much code to manually look for each reference to an integer and manually convert it.
VarType() returns 19 for these values, which appears to be some type of Long datatype that VB doesn't understand. (See here)
Isn't the ODBC driver supposed to return VarType 3 for long integers? (see here)
I tried passing the option 16384 (NO_BIGINT) in the "option=" parameter of the connection string but it didn't make any difference.
Any idea how to correct this? It seems there should be an option to pass to the MySQL ODBC driver to return longs as Long Integer datatype, but I can't find it.
Before anyone mentions it: yes we know classic ASP is bad. No we don't have the resources to port this code to something else right now. We just need it to continue working on classic ASP for the current time.
OK by the process of elimination I finally discovered the problem. Not sure why this occurs but it must be a bug in the MySQL ODBC driver.
Integer fields having the UNSIGNED attribute cause the error. Removing this attribute causes the field value to be returned as a standard Integer type. Apparently the ODBC driver is not handling the conversion from unsigned int to vbscript Integer type properly, and is instead returning a pointer to a Long.
I also noticed this problem on tinyint(1) fields which I was using as boolean values. Changing the datatype from tinyint(1) to int(11) [the default] eliminated this error also.
Hopefully this will help someone else. FYI I also posted this issue in the MySQL ODBC Driver forum but nobody bothered to respond.
Can anyone please provide advice on how to enlist in an MVCC session from SSIS?
Reading from an Ingres DB, we have a requirement to enable MVCC and specify the isolation level from within an SSIS 2008 R2 package.
An existing application exists over this database, that DOES NOT use MVCC, and hence it is not appropriate to simply enable MVCC on the existing DBMS. The reason we want our reads to enlist in MVCC is to ensure we do not cause locks and break this existing application (as is currently periodically happening when we do not use MVCC to perform these reads).
DB version is Ingres II 10.0.0 (su9.us5/132)
ADO.NET driver version is Ingres.Client.IngresConnection, Ingres.Client, Version=2.1.0.0 driver,
We have a similar requirement to do so programmatically from within Tibco BusinessWorks, and interactively via eg SQL Squirrel, and meet this need by issuing the following commands via direct SQL execution (via JDBC):
SET LOCKMODE SESSION WHERE LEVEL = MVCC;
SET SESSION ISOLATION LEVEL READ COMMITTED;
In SSIS we can set the session isolation level using the IsolationLevel property of the task/sequence. But I can find no means of issuing the MVCC command directly.
I have attempted to issue the command via an Exceute SQL Task step, but I encounter the following error:
Syntax error on line 1. Last symbol read was: 'SET LOCKMODE'
What I've tried, to no avail:
With or without the terminating ;
Execute step placed within or outside of a sequence
Enabled the DelayValidation property, at both the sequence and step level
Various TransactionOption settings at the sequence and task level (in case they mattered!)
Setting the lockmode via a windows environment variable ING_SET = "SET LOCKMODE SESSION WHERE LEVEL = MVCC". But my testing shows this is not honoured by the ADO.NET driver we're using in SSIS (nor, incidentally, is it honoured by the JDBC driver we use for SQL Squirrel or Tibco). I believe this is probably an ODBC feature.
Issuing the command from within an ADO.NET source step within a dataflow. Same syntax error.
[UPDATE] Had also tried wrapping the SET ... commands in an Ingres procedure, but this resulted in syntax errors suggesting the SET ... command is not valid anywhere within a procedure.
Can anyone please provide advice on how to enlist in an MVCC session from SSIS?
At this stage (I believe) we're constrained to the ADO.NET driver, but if there's no other option that to go with ODBC then so be it.
Answering my own question here.
Two possible approaches were conceived.
1. Use a Script Component (within a Data Flow step)
From within a script component, I was able to issue the SET ... commands directly via ADO.NET.
The problem with this approach was that I wasn't able to retain the connection on which these commands had been run, for subsequent (or parallel, within the same dataflow) ADO.NET source components.
Attempting to work via a specific connection via transactions was no good, because these commands must be issued outside of an ongoing transaction.
So ultimately I had to also issue the source select from within this component, which even then is less than ideal as the subsequent destination insert operation could then not enlist in the same transaction as the source select.
The solution using this approach ended up being:
- Using MVCC, copy the data from a source view, into a temp staging table on the source system.
- Then using a transaction, read from the source staging table into the destination system.
Code looks something like this (NB had to explicitly add a reference to Ingres .NET Data Provider\v2.1\Ingres.Client.dll
/* Microsoft SQL Server Integration Services Script Component
* Write scripts using Microsoft Visual C# 2008.
* ScriptMain is the entry point class of the script.*/
using System;
using System.Data;
using Microsoft.SqlServer.Dts.Pipeline.Wrapper;
using Microsoft.SqlServer.Dts.Runtime.Wrapper;
using Ingres.Client;
using System.Collections.Generic;
[Microsoft.SqlServer.Dts.Pipeline.SSISScriptComponentEntryPointAttribute]
public class ScriptMain : UserComponent
{
private bool debug = true;
private IDTSConnectionManager100 cm;
private IngresConnection conn;
public override void AcquireConnections(object Transaction)
{
// The connection manager used here must be configured in the Script Component editor's "Connection Managers" page.
// "Connection" is the (default) strongly typed name for the first connection added.
// In this case, it needs to be a reference to the xxxxx connection manager (by convention it should be "xxxxx_ADONET").
cm = this.Connections.Connection;
conn = (IngresConnection)cm.AcquireConnection(Transaction);
}
public override void PreExecute()
{
debugMessage("PreExecute", "Started");
base.PreExecute();
string viewName = Variables.vViewName;
IngresCommand cmdSetSessionLockMode = conn.CreateCommand();
IngresCommand cmdSetSessionIsolationLevel = conn.CreateCommand();
IngresCommand cmdReaderQuery = conn.CreateCommand();
List<string> sqlCommandStrings = new List<string>();
if (Variables.vUseIngresMVCC)
{
sqlCommandStrings.Add("SET LOCKMODE SESSION WHERE LEVEL = MVCC");
}
sqlCommandStrings.Add("SET SESSION ISOLATION LEVEL READ COMMITTED");
sqlCommandStrings.Add(String.Format("MODIFY {0}_STAGING TO TRUNCATED", viewName));
sqlCommandStrings.Add(String.Format("INSERT INTO {0}_STAGING SELECT * FROM {0}", viewName));
foreach (string sqlCommandString in sqlCommandStrings)
{
debugMessage("PreExecute", "Executing: '{0}'", sqlCommandString);
IngresCommand command = conn.CreateCommand();
command.CommandText = sqlCommandString;
int rowsAffected = command.ExecuteNonQuery();
string rowsAffectedString = rowsAffected >= 0 ? rowsAffected.ToString() : "No";
debugMessage("PreExecute", "Command executed OK, {0} rows affected.", rowsAffectedString);
}
debugMessage("PreExecute", "Finished");
}
public override void CreateNewOutputRows()
{
// SSIS requires that we output at least one row from this source script.
Output0Buffer.AddRow();
Output0Buffer.CompletedOK = true;
}
public override void PostExecute()
{
base.PostExecute();
// NB While it is "best practice" to release the connection here, doing so with an Ingres connection will cause a COM exception.
// This exception kills the SSIS BIDS designer such that you'll be unable to edit this code through that tool.
// Re-enable the following line at your own peril.
//cm.ReleaseConnection(conn);
}
private void debugMessage(string method, string messageFormat, params object[] messageArgs)
{
if (this.debug)
{
string message = string.Format(messageFormat, messageArgs);
string description = string.Format("{0}: {1}", method, message);
bool fireAgain = true;
this.ComponentMetaData.FireInformation(0, this.ComponentMetaData.Name, description, "", 0, ref fireAgain);
}
}
}
Answering my own question here.
Two possible approaches were conceived.
2. Set up a dedicated MVCC-enabled process of the Ingres DBMS over the existing database, and connect via this
This is the approach we're currently pursuing (as it is supported, and ideally transparent). I will update with details once they are known.
When I attempt to expand the stored procedures tab in Management Studio I am getting the following error and no stored procedures are displayed. I've tried re-running all stored procedure scripts (which works without errors) and refreshing the tab, but I still get the following error:
===================================
Could not continue scan with NOLOCK due to data movement. (.Net SqlClient Data Provider)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.00.1600&EvtSrc=MSSQLServer&EvtID=601&LinkId=20476
Server Name: precysesql,1433
Error Number: 601
Severity: 12
State: 3
Line Number: 9
Program Location:
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.HasMoreRows()
at System.Data.SqlClient.SqlDataReader.ReadInternal(Boolean setTimeout)
at System.Data.SqlClient.SqlDataReader.Read()
at Microsoft.SqlServer.Management.Smo.DataProvider.ReadInternal()
at Microsoft.SqlServer.Management.Smo.DataProvider.Read()
at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.NavigableItemBuilder.BuildDynamicItemWithQuery(IList1 nodes, INodeInformation source, INavigableItem sourceItem, String urnQuery, Boolean registerBuilder, Boolean registerBuiltItems)
at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.NavigableItemBuilder.BuildDynamicItem(IList1 nodes, INodeInformation source, INavigableItem sourceItem, IFilterProvider filter)
at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.NavigableItemBuilder.Build(IList1 nodes, INodeInformation source, INavigableItem sourceItem, IFilterProvider filter)
at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.NonContextFilterNavigableItemBuilder.Build(IList1 targetList, INodeInformation source, INavigableItem sourceItem, IFilterProvider filter)
at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.NavigableItem.GetChildren(IGetChildrenRequest request)
at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.ExplorerHierarchyNode.BuildChildren(WaitHandle quitEvent)
Looks like you are still on RTM; have you considered applying SP1 and CU4 to your server and client? Not that that will definitely fix the issue, but it could be a start. Also try recycling the SQL Server service. There seems to be some activity going on that is affecting access to catalog views.