none
Problems after upgrading report form SSDT 2010 to 2015 RRS feed

  • Question

  • Today I upgraded some reports from SSDT 2010 to 2015. Most of them seem to be OK although the one that I most want to work on has developed problem. When I switch to the Preview Pane I get the errors message "An error has occurred during local report processing".

    The report worked immediately after importing but started to produce this error after some simple changes where made. Thinking the obvious, I deleted the project and replaced it with a fresh copy of the SSDT 2010 version, but now I get this error before any changes are made. The report continues perfectly well in SSDT 2010, and when deployed to a Report server.

    Compared to the other reports in the project this report has a lot more columns (about 50) and is the only one based on the  List object, the others are Table or Matrix reports, I try to stay away from List. It is basically a pretty simple report though.

    There are no errors and just a few warnings, some to with overlapping objects and one that says "Custom parameter layout was removed from the report. SQL Server 2014 Reporting Services and earlier do not support custom parameter layout." which refers to another report.

    Any suggestions on what to do would be much appreciated.

    EIDIT. On the off chance, I tried something that worked. I created a new project, copied the report RDL file to it and added it to the new project. Now it works.  I can only think that some corrupted information about the report was caches somewhere outside the report project folders which survived even after I deleted the original report folder and copies in a fresh one.


    R Campbell


    Wednesday, February 13, 2019 9:31 AM

Answers

  • Hi Dick Campbell, 

    For report in SSDT, you need to follow my above suggestions. If you deploy the datasource in report server, you could use stored credential, then you don't need to pass credential each time you view report.

    Did this help you solve your issue? If so and if you'd like to, you could mark corresponding post as answer or share your solutions. That way, people who in this forum and have similar issue will benefit from it.

    Best Regards,
    Zoe Zhi


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Marked as answer by Dick Campbell Monday, February 18, 2019 8:14 AM
    Monday, February 18, 2019 6:59 AM
    Moderator

All replies

  • the message with the overlapping is more or less normal. 

    is more just a info for you. 

    do you have in your old Project DLL References ? 

    if you create a new Project this Kind of info is lost. 

    e.g. for SCCM you Need to add the DLL if you like or Need to add the RBA FUnctions to it. 

    sometimes is will also help - Import report by Import and check this out. 
    whenever you start the preview - the Background will check all Reports inside the Projects. 
    Maybe the error is not from the report you try to open. 

    Please Mark This As Answer if it solved your issue
    Please Vote This As Helpful if it helps to solve your issue

    N 48° 8' 39.8419" E 11° 36' 1.3359"


    Klaus

    Wednesday, February 13, 2019 11:29 AM
  • the message with the overlapping is more or less normal. 

    is more just a info for you. 

    do you have in your old Project DLL References ? 

    if you create a new Project this Kind of info is lost. 

    e.g. for SCCM you Need to add the DLL if you like or Need to add the RBA FUnctions to it. 

    sometimes is will also help - Import report by Import and check this out. 
    whenever you start the preview - the Background will check all Reports inside the Projects. 
    Maybe the error is not from the report you try to open. 

    Please Mark This As Answer if it solved your issue
    Please Vote This As Helpful if it helps to solve your issue

    N 48° 8' 39.8419" E 11° 36' 1.3359"


    Klaus

    Thanks for the suggestions. As mentioned in my note, creating a new project and copying.adding the report RDL to that seems to have solved the problem. Previously, I had deleted the project (in Windows Explorer) and copied the original SSDT 2105 reports back in, to the same folder structure. This didn't fix the problem some I wonder whether there was some corrupted files relating to the report cached somewhere else.

    Creating a totally new report and copying the SSDT 2015 RDL into that, fixed the problem


    R Campbell

    Wednesday, February 13, 2019 9:33 PM
  • Hi  Dick  Campbell,

    So it seems that you solved this problem, right? If so and if you'd like to, you could mark corresponding post as answer or share your solutions. That way, people who in this forum and have similar issue will benefit from it.

    Thanks for your understanding and support.
    Best Regards,
    Zoe Zhi



    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, February 14, 2019 6:08 AM
    Moderator
  • So far I really only have a work-around. Starting a new project every time there is a problem is hardly a solution.

    Also, during the course of today it has become apparent that the problem might be that the development computer and the target databases are on different domains. I specifically asked that it be on the same domain but that is not what what was delivered.

    The report has a single data source, normally with windows security but for development I am currently using SQL security to access the databases across the domain boundary. It seems to be that when I configure credentials in the data source with the Save tick box checked, there are problems with the Preview. If I don;t tick the box to save the data source credentials , when I go to Preview,  it asks for them and the Preview seems to work. Is there a place that I can save the SQL credentials so that both the data source and Preview will work, without prompting.


    R Campbell

    Thursday, February 14, 2019 7:40 AM
  • Hi Dick Campbell,

    I test this in my environment, I find that when I use embedded datasource(check "save my password" option), it will prompt error. But when I change it to shared datasource and save sql server authentication in datasource(check "save my password" option), it will work well. This might be caused by tool.

    So I suggest you use shared datasource in your project. 

    Best Regards,
    Zoe Zhi


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, February 15, 2019 9:02 AM
    Moderator
  • Thanks. I AM using an embedded data source so perhaps a shared data source will work better as you suggest, not that there is an obvious reason why it would. If it works, it works. Part of the problem is that the development environment is in a different domain to the production database, not my choice, in fact against my wishes. This has caused me to use SQL security with password savings rather than Windows security. I won’t haves chance to test this until next week now. Thanks for the suggestion.

    R Campbell

    Friday, February 15, 2019 11:44 AM
  • Hi Dick Campbell, 

    For report in SSDT, you need to follow my above suggestions. If you deploy the datasource in report server, you could use stored credential, then you don't need to pass credential each time you view report.

    Did this help you solve your issue? If so and if you'd like to, you could mark corresponding post as answer or share your solutions. That way, people who in this forum and have similar issue will benefit from it.

    Best Regards,
    Zoe Zhi


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Marked as answer by Dick Campbell Monday, February 18, 2019 8:14 AM
    Monday, February 18, 2019 6:59 AM
    Moderator
  • Hi Dick Campbell, 

    For report in SSDT, you need to follow my above suggestions. If you deploy the datasource in report server, you could use stored credential, then you don't need to pass credential each time you view report.

    Did this help you solve your issue? If so and if you'd like to, you could mark corresponding post as answer or share your solutions. That way, people who in this forum and have similar issue will benefit from it.

    Best Regards,
    Zoe Zhi


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thanks Zoe Zhi,

    I actually had a chance to test this on Sunday and it is a reasonable work around. I can use a shared data source for Preview, with saved SQL password, on the dev. environment and change to an embedded data source, with Windows credentials, before deploying to production (otherwise the shared data source also has to deployed too).

    Can I suggest that the error message in the Preview window could be more informative. We spent an hour or two looking for problems in the report design before realizing that it was a login problem. Rather than just saying "something went wrong" it would be be better to say that the login credentials failed for user ddd\uuu (domain\user).

    Thanks again for you suggestion.


    R Campbell

    Monday, February 18, 2019 8:14 AM