Firstly, I'd ask what is behind the requirement to run the subscription using T-SQL? That really defeats the purpose of setting up the subscription in the first place. When you create a subscription you're saying "run this report, with these parameter values, at this time".

Using a data-driven subscription, you're making the parameter values dynamic, but you would still have the SQL Agent job running the subscription at the specified time.

If you disable the SQL Agent job and run the subscription yourself, you're saying "I don't want to run the report at the time I specified". You'd also have to make sure that the job stays disabled in case someone inadvertantly enables it.

Personally, I'd put some effort into running the reports programatically via the web service. That removes the subscription, its stored parameters and the associated SQL Agent job.

This article has an example of rendering a report via the web service and saving the results to a file,

http://msdn.microsoft.com/en-us/library/reportexecution2005.reportexecutionservice.render(v=SQL.100).aspx

Also, @daniel-2 Bowlin, saying "All SSRS subscriptions are SQL Server Agent Jobs" is not entirely correct. The SQL Agent job is purely the triggering mechanism for the subscription. All the job does is put the subscription ID into the EventData table in the ReportServer database. Once that is done the job is complete. The Reporting Services service polls that table to find the subscriptions that need to run.

Use this instead of linking directly to the sysjobschedules table and you avoid returning duplicate rows when the SQL Agent job has many schedules,

SELECT

[job_id]

,MIN(CASE

WHEN next_run_time > 0

THEN DATEADD(ss, (CAST(next_run_time/10000 AS INT)* 3600

+ (CAST(next_run_time/100 AS INT)%100)*60

+ (next_run_time%100))

, CAST(CAST(next_run_date AS VARCHAR(8)) AS DATETIME))

WHEN next_run_date > 0

THEN CAST(CAST(next_run_date AS VARCHAR(8)) AS DATETIME)

ELSE '1900-01-01'

END

) AS NextRunTime

FROM msdb.dbo.sysjobschedules

GROUP BY [job_id]