Hello!
I have two questions that are somewhat related... (or not). They both stem from something I was told a long time ago about SSRS not being able to update information in the system.
1) When we went live with Tess back in 2011 I was told that custom subscription forms would have to be built in Infomaker. I believe this is because behind the scenes printing a renewal notice would update the subscription summary table. But since then I've been led to understand that there are definitely organizations out there that use SSRS for their renewal notices. Do your forms not make any database changes behind the scenes or have the rules changed over the years?
2) I'm beginning to venture down a brand new road and am looking into creating a couple of custom screens in the custom tab of the constituent record. Having never done anything like this before, I've been trying to research how one would accomplish such a feat. Similar to my report issue above, I was under the impression that custom tabs that were going to allow updateable fields had to be built in Infomaker. But while reading some of the documentation I've found I noticed that they mentioned SSRS with updatable capabilities. Has anyone built a custom screen that stores and updates information using SSRS and can verify this is possible before I get started?
Infomaker is definitely not my tool of choice but I'm not sure if SSRS can do what I want it to do. Looking for any advice you may have! I'd also love any do's/don'ts you may have for someone looking to build a custom screen for the very first time. :)
Thanks!
Beth
Here's my understanding -- it may help:
When the updates are being made by a stored procedure in the backend, and a datawindow or report is displaying the results, it does not matter whether you use SSRS or InfoMaker. What InfoMaker is capable of doing (while SSRS is not) is displaying the data itself, allowing edits to the data in the datawindow, and then making an update to save that data back into the database.
Where you can get creative with SSRS is in having "buttons" or items in your SSRS report with an action that runs a new (sub)report with different parameters. Since running that report is causing a stored procedure to be executed in the backend, you can "emulate" updates in a way. But there are no out-of-the-box SSRS Report elements that would be considered "controls". That said, I believe it is theoretically possible to build your own custom report elements that might lift some of these restrictions. Would be interested to hear from anyone making use of custom SSRS elements.