Craig,

I understand that.

My concern is that Subscribers can ONLY return a HRESULT (which by itself is just fine) but if there is more than 1 subscriber then *ANY* HRESULT (of COM+'s choosing, apparently) is returned RATHER THAN a "FAILED" HRESULT if 1 of the subscribers fails.

I can't see, therefore, how I can consider this 'model' for mission critical components, because if 1 of several FAILs then there is likely NOT a return to indicate that fact (any "SUCCESS" HRESULT) is more likely to be the one).

I started another thread this morning asking how/where to submit a ER to get this changed. I believe that there is great merit to the publisher/subscriber (persistent) feature, but only if any FAIL HRESULT can be GUARANTEED to be the one returned to the publisher.

Do you know where/how to do this? Is this something that I should try to convince the VFP Team of its merit and then they can submit it?

Jim



>Jim,
>
>You only inherit the interface from the the parent class. The implementation is in the child classes.
>
>>I can see dealing with failure on the publisher side. I think I have a few options there.
>>But it is the subscriber that troubles me. I don't see how I can tell that it completed (heck, I don't even (seem to) know that it was even run), let alone completed successfully. Writing to the event log will let a person see that there is trouble, but what about the application? Looks like I can only use this for application bits that are irrelevant to the main processes. Sort of like 'nice to haves' and 'hopefully most of the times it will run' kind of things. I really haven't done many (none, really) like that.
>>
>>I really think I must be missing something basic here.
>>
>>Jim
>>