| 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 |
