dmauri:
Gia, questo è il problema che si crea quando l'architetto che sviluppa l'applicazione (Reporting Services in questo caso) suppone che l'accesso ai dati della stessa sia fatto solamente ed unicamente tramite lo strato applicativo, i Web Services in questo caso.
Su questo punto sono perplesso.
Quello che ho fatto io è stato semplicemente usare ReportManager, quindi operando in maniera assolutamente standard e "ufficiale", assolutamente nulla di forzato.
Nel mio caso specifico, l'operazione di modifica job non va a buon fine a causa di un mismatch utenza tra l'owner del job e l'issuer del comando di modifica della schedulazione, ma il punto non è quello... l'errore potrebbe essere [whatever].
Resta che l'applicazione mi ha modificato il record sul "suo" db, però ha fallito nell'updatarmi il job su agent: di questo mi riporta, bontà sua, un output di errore nella pagina web, peccato però che ormai a livello di Report Manager la modifica sia "committata" e risulti la schedulazione che io a questo punto ho solo l'illusione di avere applicato: tant'evvero che se rientro nella pagina è quella che vedo, e non quella effettiva (e vecchia) che è rimasta su sqlagent... per evitare pericolosissime "illusioni ottiche" non resta che re-impostarla a mano in modo coerente a quanto risulta sull'agent. 
Forse, dal momento che poi la schedulazione che davvero "parte" è quella di agent, si sarebbe potuto almeno prima tentare l'operazione su sqlagent e POI solo a fronte di buon fine di questa aggiornare anche la tabella applicativa SCHEDULE. O ancor meglio, "ricordarsi" i valori precedenti e avere cura di ripristinarli in caso di errore nell'operazione di update su sqlagent!
Ovviamente, grazie per tutte le utilissime indicazioni!
Matteo