Roger,

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

>Hi Jim,
>
>I've just started to play with COM+ stuff as well but I think the answer to dealing with failure of the subscriber or publisher would be to write to the Win2k event log and return. As services they have no user interface and there may not even be an operator around to react.
>
>
>>I have read the subject section in the "VFP COM+ Services Samples" in the VFP7 documentation as well as in the "What's New in Visual FoxPro 7.0" book from Hentzenwerkes. Using the book's instructions I ran the related sample (from the VFP Samples included in the (VFP7) product material) and examined the code associated with it. [note: I confined the sample running/examination to the "publish/subscribe" part only]
>>
>>While the entire arrangement struck me as a bit strange (particularly a class of empty methods as the 'Event Class'), it is simple enough of a procedure. After looking through the code I think that I have a basic understanding of the mechanism for publisher/subscriber COM+ events.
>>
>>The sample does leave several questions in my mind that I hope can be answered here:
>>
>>I surmise (didn't see a definitive statement in either document) that there can be no RETURN value of any kind from a "subscriber" object. After all, there can be many subscribers to a single publisher and how would the 'publisher' handle multiple returns?
>>1. Assuming this to be correct, what would be a practical use for these "events"?
>>---Even for the simple example provided, where the subscriber simply records the change to a .TXT log file, what value would the LOG file have if there was a problem writing a LOG record (like, say, the HD to contain it was full or the file had been changed to be read-only)???
>>The best that I can come up with would be to launch some other application (say Word or e-mail or IE or . . .) which the operator may or may not use as expected/directed.
>>
>>2. Does the publisher process wait for completion of (all) subscribers or does it proceed independently?
>>
>>3. What happens if one or more of the subscribers has a problem during processing?
>>
>>4. What happens if someone attempts to change one or more of the subscriber components?
>>--- Is the person attempting the change notified at all that it is a "subscriber"? If so, when?
>>--- Is any 'adjustment' to the COM+ "catalog" necessary and, if so, is it done automatically or is it a manual process?
>>
>>5. A COM+ application can consist of multiple COM components that are "administered as a unit and run in the same process". Would one do this to optimize the response when a known group of VFP COM servers would be expected to be used by a regular application or is there some other need for this?
>>--- Can at least one of the subscribers be included in the COM+ application definition? Could they all?
>>--- Can a subscriber be on a different server or must it reside with the publisher(s)?
>>
>>6. Are COM+ applications and COM+ events mutually exclusive to other COM+ features (like Queued Components) or can they be integrated together?
>>
>>Thanks for your patience and responses
>>
>>Jim Nelson