news:C9A67E5E-51B7-43C7-9FDF-6FEFCB411DEE@microsoft.com:

> I have a DLL that handles connectivity with my SQL database.  There
> will be several applications creating an instance of this DLL for
> their data needs, all operating on the same common table(s).  The DLL
> has a method that Raises an Event when it deletes a record (the intent
> is that applications that have an instance of the DLL will be able to
> refresh their views of the data).  I was under the assumption that
> desinating the Event as a Shared Event would allow ALL instances to
> receive the event.  This is not what is happening.  Currently, only
> the application that is requesting the Deletion is receiving the
> Event.
>
> Any thoughts about what I'm doing wrong?  Are my assumptions correct?

"Spam Catcher" wrote:

> =?Utf-8?B?U2Ft?= <S**@discussions.microsoft.com> wrote in
> news:C9A67E5E-51B7-43C7-9FDF-6FEFCB411DEE@microsoft.com:
>
> > I have a DLL that handles connectivity with my SQL database.  There
> > will be several applications creating an instance of this DLL for
> > their data needs, all operating on the same common table(s).  The DLL
> > has a method that Raises an Event when it deletes a record (the intent
> > is that applications that have an instance of the DLL will be able to
> > refresh their views of the data).  I was under the assumption that
> > desinating the Event as a Shared Event would allow ALL instances to
> > receive the event.  This is not what is happening.  Currently, only
> > the application that is requesting the Deletion is receiving the
> > Event.
> >
> > Any thoughts about what I'm doing wrong?  Are my assumptions correct?
>
> Shared Events are only valid in the current AppDomain, events are not
> propogated to other instances (imagine if the events did propogate...
> that could be a major security issue!).
>
> What you need is a N-Tier design - your clients need to connect to a
> middle tier which acts as a broker between the backend  (data tier) and
> the display tier (GUI/client). When the client (GUI) submits a delete
> record to the middle tier, the middle tier submits the request to the
> data tier. When the data tier successfully deletes the record, the
> middle tier informs the clients to update their view.
>
> Some technologies you look at include:
>
> Web Services (requires polling to do what you require)
> Remoting / WCF
>
> Personally I'll recommend remoting since you can do bi-directional
> communications with a little persistence. If you go the remoting route,
> take a look at Geninue Channels which will speed your development
> greatly.
>
> SQL Server notification services can also be used to notify the clients
> - but for what you want to do, you're probably better off building your
> own custom tier.
>
> So what you like to do is not trival - you'll need to do some planning
> and reading up on multi-tier application architecture.
>
> Since you're clients are working with disconnected data... you'll also
> have to handle concurrency (Client A deletes a record while Client B is
> working on it. Client B then saves the record...).
>
> Also take a look at LLBLGen Pro - it's a data layer generator. It can
> provide you with a good foundation to layer your tiers on top of.
>
> Feel free to post a reply if you need more clarification.
>