After wasting a few hours, I've decided it's not worth it to proceed any further. If you want to know the schedule (or just the next-run-time) of a subscription, just go to the SSRS web site (the web UI). It's too much of a pain to use the ReportingService2005 interface.
The simple back-story to this is that I've made an app that handles uploading (create/update) all of our reports (.RDL files) from the local computer to an SSRS instance. Doing this through the web UI is incredibly tedious, error-prone, and my Carpal Tunnel flares up after a few reports. So now that I'm done, I decided that it would be nice to see information about all of the various subscriptions that people have defined for the various reports.
It's not hard to add this in. You just call ListSubscriptions(null, null) after logging in with an admin account. But the Subscription object has no information about the schedule it runs against! Well, actually it can tell you a few things via the LastExecuted, Status, & EventType properties, but I'm really liking the information in a Schedule object.
So maybe if you start with Schedule objects and find a way back to a Subscription on a Report? Nope. ListSchedules() and ListScheduledReport() only work on "shared" schedules; if you define a schedule when you're defining a subscription (via the web UI), your schedule isn't returned by those 2 methods. And it wouldn't matter anyhow, because the Schedule object does not have anything linking it to a Subscription or a Report.
There is only one possibility left that I'm aware of: get a ScheduleDefinition object in one of two ways:
It seems the more I work with SSRS, the less I like its architecture. I considered it an "epic-fail" back when I had to deal with implementing a custom security extension (e.g. RSReportServer.config's "Dsn" and "URLReservations" tags---SSL support is broken because the UI doesn't use relative paths and hard-coded "http" is all over the place---the list goes on and on). Now they're just taunting me.
The simple back-story to this is that I've made an app that handles uploading (create/update) all of our reports (.RDL files) from the local computer to an SSRS instance. Doing this through the web UI is incredibly tedious, error-prone, and my Carpal Tunnel flares up after a few reports. So now that I'm done, I decided that it would be nice to see information about all of the various subscriptions that people have defined for the various reports.
It's not hard to add this in. You just call ListSubscriptions(null, null) after logging in with an admin account. But the Subscription object has no information about the schedule it runs against! Well, actually it can tell you a few things via the LastExecuted, Status, & EventType properties, but I'm really liking the information in a Schedule object.
So maybe if you start with Schedule objects and find a way back to a Subscription on a Report? Nope. ListSchedules() and ListScheduledReport() only work on "shared" schedules; if you define a schedule when you're defining a subscription (via the web UI), your schedule isn't returned by those 2 methods. And it wouldn't matter anyhow, because the Schedule object does not have anything linking it to a Subscription or a Report.
There is only one possibility left that I'm aware of: get a ScheduleDefinition object in one of two ways:
- GetSubscriptionProperties() - This is a very cumbersome method, and the only thing you get from it that a Subscription object doesn't already have is in the "MatchData" parameter. It returns an Xml-serialized ScheduleDefinition object. Deserialize it, and you can then do the additional work of casting the Item property to the appropriate type and re-calculating the data that a Schedule object would have already had available to you. Oh boy.
- GetExecutionOptions() - This should be better only because it should return you an object (rather than having to deserialize some Xml). But what happens if multiple users have defined multiple subscriptions on the report? It doesn't return a list, so either it fails or only returns one of the schedules (definition or reference).
It seems the more I work with SSRS, the less I like its architecture. I considered it an "epic-fail" back when I had to deal with implementing a custom security extension (e.g. RSReportServer.config's "Dsn" and "URLReservations" tags---SSL support is broken because the UI doesn't use relative paths and hard-coded "http" is all over the place---the list goes on and on). Now they're just taunting me.
Comments