| Event Id | 208 |
| Source | SQLSERVERAGENT |
| Description | SQL Server Scheduled Job "<job name>" (0xAC8952C0A18BEA4FABCD341D3D982CC6) - Status: Failed - Invoked on: <date and time> - Message: The job failed. The Job was invoked by Schedule 2 (<job name> 2). The last step to run was step 1 (<job name> 2). |
| Event Information | Following information from newsgroup post may help: "SQL Server Scheduled Job MessageBox_Parts_Cleanup_BizTalkMsgBoxDb (0x[GUID]) - Status: Failed - Invoked on [Date] - Message: The job failed. The Job was invoked by Schedule 13 (Schedule). The last step to run was step 1 (Purge). Suggested Solution: Some time last week I played with "Publish Schema as a web service" option of the BizTalk Web Services Publishing Wizard. When i created that web service i specified a particular message schema as a type for one of the web service operations. Apparently, that was a mistake, as all messages of that type started to be sent to that web service, regardless of where they *should* have been sent! So if a request came in on a different web service (Request/Response pattern), the Response to the request was sent to the "test" WS Id created via "Publish Schemas as a web service" option, rather than to the web service that received the Request! (This, as a consequence, caused the web service clients to time out, as they never got a response from me, even though the successfully sent a message...) Im guessing here now because Im not an expert on BizTalk database internal processes, but the fact that all messages of the misdirected type were now "delivered, not consumed", the delivery queue started to pile up, especially as i was doing more and more frenetic "testing". I dont know how this affected the part purging job, exactly. i do know, however, that when i tried to run the bts_PartsPurge sproc directly, i got an error message (which i failed to record, sadly). The gist of the error (or as well as i remember it) was that the number of Parts exceeded the storage capacity provided by a signed short integer (>32K), and so the sproc bombed out. I think the upcoming SP1 script would have helped me out by clearing the MsgBox db of debris, but i resolved my problem by removing & reinstalling BizTalk & starting fresh with ne |
| Reference Links | Error When Direct Mailer Database Name Contains Spaces BUG: The "Backup BizTalk Server" SQL job fails with an error because the adm_OtherBackupDatabases table is not created |
Catch threats immediately
We work side-by-side with you to rapidly detect cyberthreats
and thwart attacks before they cause damage.