When I am trying to execute few reports in ReportManager its throwing error.
The attempt to connect to the report server failed.Check your connection information and that the report server is a compatible version.
There is an error in XML document(1,134206).
'',hexadecimal value 0x0C, is an invalid character. Line 1, position 134206.
When I execute form report server it executing successfully.
The same rdl file is working perfectly in other System using ReportManager.
What can be the issue?
And how can we produce this error in the working system? And how can we solve this error?
The character producing the error is 0x0C, which is a char FF, escaped as \f,
sometimes used as a page or section break.
As a first troubleshooting step you can remove this char and see if the report works.
You can find this char in your rdl if you open it with Notepad++, for instance,and search for \f (in search mode extended). You can then remove this char and rerun.
The second step is to determine why it works in one system and not in another, which could well be down to a difference in the SSRS and/or OS version of the systems in question.
In one of the field, there is some invalid character as in the image.
And report Manager is unable to process it while executing rdl file.
We got the DB backup from the client and replicated in other systems as well.
Invalid Character
Related
I want to use Excel Power Query to import JSON data from web and transform the data afterwards. I have 2 versions of JSON Data, one development version and one live version. Both versions had no problem prior to last week and could connect without any issues.
Last week the live version stopped working and couldnt connect through Excel or PowerBI anymore. Curiously, nothing has been changed in both versions that could've contributed to this error happening, there were absolutely no hands in either versions during that time frame.
This is the dev connection string in PowerQuery thats working without problems.
Source=
Json.Document(Web.Contents("https://www.dev.com/dummy/YXC/JSONDATA")),
Now when I try to change it to this
Source=
Json.Document(Web.Contents("https://www.live.com/dummy/YXC/JSONDATA")),
the error message: "[DataFormatError] We found extra characters at the end of JSON input." arises
After this and some troubleshooting, I opened a new empty Excel file to put the link directly into the "from Web" tab. The connection fails and I get up to 2 Errors.
"[DataFormatError] We found extra characters at the end of JSON input."
"Details: The Ressource under "https://www.live.com/dummy/YXC/JSONDATA" cant be opened through Web.Page since its apparently no website"
Before the website can be openend one must have an authorized microsoft organisation account.
In Chrome the data shows up without any issues and there are no authorization issues, also when I download the JSON data and import it through a file directly there are no issues either. Same error occurs with other accounts.
Since it says DataFormatError, I started looking into the JSON Data. The JSON Data doesnt have any whitespace and is identical with the working dev version.
Does anybody encountered this or has a clue on how to fix this?
Usually, in a dtsx Standard Report, there is a column "Message Source Name" that indicates which dtsx threw the error or raised the event.
Now i get "Transact-SQL stored procedure" and of course I don't have such a dtsx.
So, question #1 is: Where should I go to check the error?
Besides, the error is: An error occurred while setting the value of a property "InitialCatalog". The error returned is 0x80020009. The connection string components cannot contain unquoted semicolons....
My dtsx were doing fine and I was publishing dtsx on a regular basis with no problems. Then, I changed the name of a ConnectionManager and took care of changing this name wherever it appeared.
After this fateful move, I cannot manage to restore the previous situation. Even rollbacking all changes through TFS and going back to the previous names doesn't solve the matter.
I checked also the environment I am using and the configuration of the job that launches the dtsx, to no avail.
If I execute the dtsx on my development machine, from visual studio, it works fine. The problem arises in production enviroment when I use the job configured with the environment. In the project configuration and in the environment configuration I don't see what an "unquoted semicolumn" could be.
The value of the connection string that is indicated as having an error looks like:
Data Source=11.1.1.11,1111;Initial Catalog=MyDB;Provider=SQLNCLI11.1; Integrated Security=SSPI ;Auto Translate=False;
Question #2 is: Where could this connection string with unquoted semicolon be?
Thx.
With much effort I managed to find an answer to Question #2:
I am using parametrized connection managers, so I have a project parameter (let's call it PP1) in my dtsx with the connString.
During configuration of the SSIS project I need to give a value ONLY for the parameter PP1, and NOT for the connection string.
What I did wrong was to give the Environment Variable with the connString to the Property "Initial Catalog". Therefore, SSIS was lamenting of the presence of ";" (the ones in the connString) in the InitialCatalog.
5893.1
Hi all,
I have searched and got answers for my questions many times from this forum. However, I now have a question that I don't think anyone has asked before.
We use Windows DOS batch to compact MS Access 2010 DB files everyday. It seems Access does not pass any return code to DOS. So my question is: Is there a way to tell whether the compacting is successful or not from within the batch?
We use Win XP/7 machines for development, and Windows Server 2008 for production. We are running MS Access 2010.
The DOS batch has a line like "D:\Microsoft Office\Office14\msaccess.exe" %DBLoc%%BkupFile% /compact %DBLoc%%DBFile%
Any help is much appreciated.
Doesn't appear that there is a return code.
However, one time-tested technique is to pipe the output from the command to a text file and then test the contents of the text file. That way, if there's an error message printed at least you'll be able to catch that.
eg. add ' > test.txt' to the end of the command line.
You'd have to check on the available command shell tools to read the text.
You may also have to specifically redirect the error output separately from the command output. see here for redirection info : http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true
Edit: to head off the next question, some links on detecting the failure message in the text file
http://ss64.com/nt/findstr.html
How to set variable with the result of findstr
I have created a report an SSRS report in VS 2008, and running it on a Windows Server 2012. When I run the report from Report Manager, it runs with no issues. However, when I set up a scheduled subscription, I get the following error message: Failure sending mail: An error occurred during rendering of the report. Mail will not be resent.
I have tried a number of Render Format options, including Excel, Word and CSV. It has failed on each of these formats. I did try the 'XML file with report data' option and the mail was sent. I also used the 'Include Link' option without including the report and that worked.
I have also set the Report Timeout option to 'Do not timeout report' in the Processing Options but still got the problem.
I am also running another report that is identical, except for the time interval and it runs fine. The report that is failing captures weekly data, while the report that runs OK captures monthly data.
Any ideas of what is going on with this report? I have provided all the information I can think of, but if anyone needs anything additional, please let me know! Thank you for your assistance!
Although I am not 100% certain of this, after I changed the name and removed some special characters (primarily parenthesis) and this seemed to clear it up.
Edit: After a significant span of time has passed I am certain that this was not a fix. I have a couple of reports that seemed to run fine for a while but then failed. When running the report from Report Manager it runs fine, and can be exported without any problem.
I subsequently ran the report from Report Manager and exported it into a .csv file. After opening this file in a text editor, I noticed that there were double quotation (") marks randomly distributed throughout the report. This did not show when exporting to excel. I rewrote the script to replace the quotations with blank spaces. I ran it again from Report Manager and exported it again to .csv and there were double quotes in the result. When I do this from SSMS I don't get the double quotes. It appears then that this occurs as a result of the export. The report will display in Report Manager, but won't go out in subscriptions.
Any ideas or suggestions would certainly be appreciated. I have worked on this for a while now (months) and need to come to some resolution. Thanks!
The solution ultimately was found and solved by updating the sql server with a service pack that was missing.
I have the following vba-code in an MS-Access97-frontend which opens a word-document stored on a server:
Call Shell("winword ""\\Fileserver\Contabilita\Crucial deadlines\Bonifico97.doc""", 1)
The document is a merge-document (getting data from a query and populates the document from the data retrieved)
Now, I have put the database-frontend on another computer (still using MS-Access 97 but with MS-Word 2003 installed on the PC - MS-Access 97 is still working nicely since it was installed in a different directory) but now when above code, using call shell, is being executed, I always get "Document not found". If I launch above shell command in Start/execute, the document is being opened correctly.
What could be the problem? The file-path? Did any anything change in VBA 97 and VBA2003 what regards file-paths? I am aware of the fact that there is a folder in the file-path with a space but it works nicely on the PC with office97 installed.
I would appreciate any help I can get. Thank you.
You will need to use the full path for Word.
Alternatives to using SHELL with the full path specified for Word would be:
Application.FollowHyperlink
ShellExecute
In either case, you'd be opening the file with the application associated with the file association of the file you're opening. The only reason to stick with Shell() is if you're using the PID returned by the Shell() function to control the application after it's run. But your original code used Call Shell... so that wasn't an issue.