I have a datasource that is working
I add a Stored Proc, it tests OK
I click test connection at the bottom and I get this
I remove the stored proc and the test connection works.
Hey Chris,
I will take a closer look at your description and try to recreate it. An idea that could possibly work as a workaround in advance:
- Please edit the selected stored procedure again
- Select “Test Routine Query” again and then “Apply”
- The connection test should now also be performed successfully
Please note, however, that only when accessing via the Designer, when the actual data structure of the stored procedure is completely queried and prepared, will the function work.
I will get back to you as soon as I have more details after consulting the development department.
Hey Chris,
We have now implemented a small enhancement in this area and we would like to provide it to you. However, for this purpose, you would need to create a case in the support center, so that we can supply you with the appropriate patch for the version you are using.
Thank you.
Thank you, that patch did fixed the issue.
I did run into another issue which is probably unrelated and might be working as designed.
I have two databases, with the same stored procedures. If I point my datasource at one database it works, if I point it at the other database it does not work. Are the stored procedures being stored with some kind of unique id rather than just their name?
Hey Chris,
Thank you for your feedback confirming that the patch solved the original issue.
However, as far as the new observation is concerned, we need more information from you so that the development team can analyse this more precisely:
I have two databases, with the same stored procedures. If I point my datasource at one database it works, if I point it at the other database it does not work.
Could you please provide us with a more detailed description of your activities here, so that we may understand and replicate them on our end? We would like to examine this matter more closely. Should the description prove too extensive, feel free to submit it in a new support case as before. Thank you for your additional help.
Best regards,
Daniel Stein
No problem.
Step 1, setup data source add some stored procs.
Test the connection
Step 2, point to a different database, same server, and same stored procedures
Test the connection
click save, and test the connection again
point back to original database, and test the connection, and it is good.
1 Like
Hey Chris!
Thank you for your detailed description.
The notification in question is triggered when the Stored Procedure is included in the cattax_db1_qa database but does not exist in the cattax_db1_qa_clean database. However, the phrasing of the message is misleading, which we will now adjust accordingly.
Should you wish, please do create another support case for this, so that I can provide you with the patch as a modification if available. Otherwise, the change will also be delivered in one of the upcoming service packs.
Thank you for your help!
Best regards,
Daniel Stein
Actually there is a stored procedure of the same name in each of the two databases. Which is why I was wondering if it was going by something other than the name? Because cattax_db1_qa is just a backup and restore of cattax_db1_qa_clean
With our tests we coud not see this behavior. Hopefully you have backed-up also the stored procedures as well and they are also fully restored by the system as expected. But I think that you have already checked something so simple in advance. So I suspect something more specialised in the database structure that we need to look at.
It would be the best, if we can made some more detailed analyses on this. But we need your both used databases for doing this and also your configured data source (Management > Import / Export > Export) in Report Server. Please sent us all the data within a new support case. Thank you for your continued support.