April 4, 2024 at 6:00 pm
I have upgraded the SSRS 2017 to 2019 recently after that I am not able to edit DDS subscriptions getting error saying that someting went wrong please try latter .Please suggest me how to slove this issue. Please see the log.
024-04-04 10:21:22.0935|INFO|145|Received request POST /api/v2.0/DataSources/Model.GetQueryFields| RequestID = s_92f7866c-775d-4c15-8e3d-51a290c28a5a
2024-04-04 10:21:22.0935|WARN|145|BadRequest, Errors: | RequestID = s_92f7866c-775d-4c15-8e3d-51a290c28a5a
2024-04-04 10:21:22.0935|INFO|140|Sending response. Response code GENSLERAD\23629 400, Elapsed time 0:00:00.002548| RequestID = s_92f7866c-775d-4c15-8e3d-51a290c28a5a
2024-04-04 10:21:22.0935|INFO|145|Received request GET /api/v2.0/schedules| RequestID = s_fefce86f-3d76-4906-ac59-2274bb4528f0
2024-04-04 10:21:22.0935|INFO|138|Sending response. Response code GENSLERAD\23629 200, Elapsed time 0:00:00.0031198| RequestID = s_fefce86f-3d76-4906-ac59-2274bb4528f0
2024-04-04 10:21:22.0935|INFO|145|Received request GET /api/v2.0/Reports(bf9f0d6a-5835-4302-9955-87f53a94803f)/ParameterDefinitions| RequestID = s_8800369d-5b9d-4a57-b155-d3ead235316c
2024-04-04 10:21:22.1247|INFO|126|Received request POST /api/v2.0/schedules/model.describe| RequestID = s_e57304c7-600d-44a4-ad9c-557de21de638
2024-04-04 10:21:22.1247|INFO|140|Sending response. Response code GENSLERAD\23629 200, Elapsed time 0:00:00.0027922| RequestID = s_e57304c7-600d-44a4-ad9c-557de21de638
2024-04-04 10:21:22.1560|INFO|140|Sending response. Response code GENSLERAD\23629 200, Elapsed time 0:00:00.0683577| RequestID = s_1c32c461-d656-495f-b15e-771e0300d9db
2024-04-04 10:21:23.4685|INFO|140|Sending response. Response code GENSLERAD\23629 200, Elapsed time 0:00:01.3706544| RequestID = s_8800369d-5b9d-4a57-b155-d3ead235316c
2024-04-04 10:21:23.4997|INFO|145|Received request POST /api/v2.0/Reports(bf9f0d6a-5835-4302-9955-87f53a94803f)/Model.ProcessParameters| RequestID = s_e237a3b0-8636-4468-9181-ceee8bb25519
2024-04-04 10:21:2
April 4, 2024 at 7:53 pm
As a thought - did you upgrade from 2017 enterprise to 2019 standard?
If not, do you have any other logs to look at? Those logs just say that your POST failed due to a bad request. As a guess, did the service account change when you upgraded? Did you do an in-place upgrade or a migration upgrade? If it was migration upgrade, did you set up the SPN's again and restore the certificate from backup? If it was a migration, do you still have access to the 2017 instance and if so, can you verify that it was working on 2017 prior to the upgrade?
I've seen cases where something breaks due to a patch on an older version (SP2-SP3 changes for example) and nobody notices at first. BUT after doing a major upgrade (2017-2019 for example) people start to notice.
Another thought - if you re-deploy the report to the server, does that correct the issue?
Another thought - can you reproduce this on your test system (hopefully this is on a test system and not live)? Reason being here is you have more options for experimenting.
Another thought - do you have permissions to do the changes?
Another thought - was the subscription set to run as a user who no longer exists or is disabled in SQL?
Last thought - are you fully patched 2019 or just fresh install 2019? It may be a bug that is fixed in an update.
I have lots of thoughts, but unfortunately that log is not very helpful (to me... maybe to others). To me, I can see you did a POST operation which sent some bad data (data the API didn't understand or data that would violate security settings) so it rejected it. There should be other logs from around that time that would have more details about what went wrong. Offhand, I don't know which logs would be helpful though.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
April 5, 2024 at 4:23 pm
Thank you for your reply.
I did inplace upgrade on Dev server from SSRS 2017 Dev to 2019 Dev Edition and we have DOTNET layer on top of it.
Yes it was working on before upgrade to 2019. Yes I have sysadmin permisions. It got fully upgraded without any issues.Developer also had sysadmin access. Can you please suggest on it.
April 5, 2024 at 4:43 pm
This was removed by the editor as SPAM
April 5, 2024 at 7:04 pm
This was removed by the editor as SPAM
April 5, 2024 at 7:22 pm
Did you try any of my other suggestions like re-deploying the package?
Did you get any errors or warnings when upgrading from 2017 to 2019?
Did the service account change when you did the upgrade?
When you say "sysadmin access", I don't think "sysadmin" is a permission on SSRS. That's a SQL Server permission. Do you and the other developer have "Content Manager" permissions on the report in question?
Are there any other logs (windows or SSRS) that are helpful? Would be interesting to see what the "bad request" was.
Can you make a NEW DDS for that report on SSRS 2019?
Can you try restoring the encryption key from backup (just in case something went screwy when you did that upgrade)?
Did you upgrade the SQL instance along with SSRS or just upgrade SSRS? If you ONLY upgraded SSRS, I would recommend updating SQL Server version to match the SSRS version.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply