In can be as simple as the following...
You need one class to "control" things (TheWorld). There's only one of 
these ever. Then you need a class that communicates with this control 
and calls the raise event stuff. (This class can do a lot but it is best 
if it just does stuff and raises the event and does not watch for the 
event - as per MS to prevent deadlocks.) You also need one class 
(NotifyPersist) that receives the event and passes it back to the client
In ActiveX Exe
Create a class (TheWorld) that is 4- GlobalSingleUse with
Public Event WorldChanged(ByVal dNow As Date)

and you need something like:

'********************
' RaiseWorldChanged()
'
' something changed something (AutoReq, RailTracking, Switch Order Web 
page)
' - then called this.
' Raise WorldChanged event for any object listening
'********************
Public Sub RaiseWorldChanged()

    mChangeTime =3D Now

    RaiseEvent WorldChanged(Now())
   
End Sub

Also in this ActiveX Exe create a class (WorldPersist) that is 
5_MultiUse. This class does the work and raises the event for everyone 
by raising the event in the one and only TheWorld

In WorldPersist
'************************
' Initialize()
'
' Set reference to TheWorld
'************************
Private Sub Class_Initialize()

    ' always  need  1 global TheWorld obj
    If gTheWorld Is Nothing Then
        Set gTheWorld =3D New TheWorld
        gDoIExist =3D True
    End If
   
End Sub

At startup if the ActiveX Exe (sub Main whatever)

Set gTheWorld =3D New TheWorld
where gTheWorld  is defined as:
Public gTheWorld As TheWorld


Here's what you need in NotifyPersist Code (the code that passed the 
event on to the clients):
'********************************************************************
' NotifyPersist
'
' Used to raise the world changed types events
' Does not connect to the DB so that connections can be terminated.
' Used as a "light" connection to the DLL as per MicroSoft instructions
' for preventing deadlocks/locks when creating and destroying
' DCOM connections
'********************************************************************

' This class is used for:
'
' 1 - For DLLs needing to communicate constantly
' with RailWorld, Dim the NotifyPersist object wihtout events.
' This follows MS suggestion about not constantly breaking and 
recreating
' the DCOM link to the ActiveX Exe which can cause lockups.
'
'********************************************************************
'********************************************************************
Option Explicit

Const cMODULE_NAME =3D "NotifyPersist"

Dim msErrModule As String

Public Event WorldChanged(dNow As Date)
' This event is to let all the RailWorld objects know that
' the rail_tracking data has been changed


Private WithEvents mTheWorld As TheWorld

'************************
' Initialize()
'
' Set reference to TheWorld
'************************
Private Sub Class_Initialize()

    ' always  need  1 global TheWorld obj
    If gTheWorld Is Nothing Then
        gDoIExist =3D True
        Set gTheWorld =3D New TheWorld
    End If
   
    Set mTheWorld =3D gTheWorld
   
End Sub

'************************
' Terminate()
'
' As this instance of RailWorld goes away
' subtract one from the total object instances
' that are
'************************
Private Sub Class_Terminate()

    On Error Resume Next
   
    mTheWorld.DeleteReference

'    Set mTheWorld =3D Nothing

End Sub


'************************
'
'************************
Private Sub mTheWorld_WorldChanged(ByVal dWhen As Date)
    RaiseEvent WorldChanged(dWhen)
End Sub


In Applications DLL:
Create a class (RailObj in our case)  to receive the event and 
instantiate it at start up (5 MultiUse for our purposes; NOT MTS; NOT 
persistable)

In this class watch for the event and do whatever. This connection to 
the ActiveX Exe stays connected all the time as per MicroSoft to reduce 
deadlocks.

Dim WithEvents mobjNotify As NotifyPersist

'**********************************************
'  WorldChanged
'
' A new switch was added or one was changed
' or deleted, etc.  If frmOps is open, then
' this event should cause a message to appear
' in the frmMain status bar
' frmOps is only RailTracking form looking for
' this event.
'**********************************************
Private Sub mobjNotify_WorldChanged(dNow As Date)
    RaiseEvent WorldChanged
End Sub



If someone has a better way pls let me know.

> -----Original Message-----
> From:	ramil sagum [SMTP:ramil.sagum@u...]
> Sent:	Tuesday, October 29, 2002 8:49 AM
> To:	professional vb
> Subject:	[pro_vb] RE: messaging over database users
>
> i'm having problems with the server. I can't get a user to send a 
message to
> another. i think my instancing is wrong.
>
> What instancing do i need to use to make sure they are using only one 
instance
> of the server?
>
>
>
> Quoting "Cremieux, Judith K." <Judith.Cremieux@i...>:
>
> > When User1 does the required action, you can raise an event for 
user2.
> > We do this for limited circumstances:
> > *	Case A: 3 unique processes can change the status in the "world of 
molten
> > iron" here. But many people thruout the plant need to know when 
these things
> > change. Therefore there is a method in the ActiveX Exe that will 
raise an
> > event when any of the 3 processes call it.  (This is not happening a
> > gazillion times a minute either) The clients (one of which is a VB 
app on the
> > server that pushes information to those logged onto web pages thru 
the port),
> > create an instance of a class in the ActiveX Exe that just waits to 
receive
> > the event. When they receive the event they repaint the form or BEEP 
etc.
> > *	Case B: Customers around the plant use a web page to enter a 
request to
> > move rail cars. The ASP page that stores the request in the Db 
(Oracle)
> > creates an instance of a class in a similar  ActiveX Exe . Then 
calls a
> > methot that raises an event on the Rail command centers VB 
application
> > indicating a new switch request has been saved. (We only notify the 
user - we
> > do not pop  up tje new request because the supervisor may be in the 
middle of
> > doing something else and he just needs to know that it is there.)
> >
> > Both of these work fine usually. We can have deadlocks occasionally. 

> > It is better to know:
> > How fast does this have to happen? how often will it happen? To how 
many
> > users?
> >
> >
> > > -----Original Message-----
> > > From:	ramil sagum [SMTP:ramil.sagum@u...]
> > > Sent:	Tuesday, October 29, 2002 8:07 AM
> > > To:	professional vb
> > > Subject:	[pro_vb] RE: messaging over database users
> > >
> > > I need a form to appear in user2 when user1 does something. That 
form
> > contains
> > > the details that user1 entered (which is to be found on the 
database)
> > >
> > >
> > >
> > >
> > > How do they program client/server games?
> > >
> > >
> > >
> > >
> > > Quoting "Cremieux, Judith K." <Judith.Cremieux@i...>:
> > >
> > > > DCOM can do what you want. It has drawbacks tho. For instance if 
you
> > raise an
> > > > event in the ActiveX Exe, it waits until all clients have had 
their
> > event
> > > > processed.
> > > > You may do it with MS MsgQ or since you are using SqlServer, you 
can send
> > an
> > > > email from a proc or trigger. Depends on how you want the user 
to
> > receive
> > > > this msg.
> > > >
> > > > > -----Original Message-----
> > > > > From:	Ramil Sagum [SMTP:ramil.sagum@u...]
> > > > > Sent:	Monday, October 28, 2002 8:38 PM
> > > > > To:	professional vb
> > > > > Subject:	[pro_vb] messaging over database users
> > > > >
> > > > >
> > > > > hey there.>
> > > > >
> > > > > i need help regarding our database application.
> > > > >
> > > > > there are several users all concurrently connected on a 
database
> > (running
> > > > on
> > > > > sql server)
> > > > >
> > > > > i need to be able to send a message to a user (to whatever 
computer he
> > may
> > > > > be logged on to) during certain times.
> > > > >
> > > > > for example, if a cetain user fills up this certain form, i 
should be
> > able
> > > > > to send a message to another user that
> > > > > the form was completed (plus info concerning that form)
> > > > >
> > > > >
> > > > > would DCOM be fine?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---
> > > > > Visual C# - A Guide for VB6 Developers
> > > > > This book will make it easy to transfer your skills
> > > > > from Visual Basic 6 to C#, the language of choice
> > > > > of the .NET Framework.
> > > > > http://www.wrox.com/ACON11.asp?ISBN=3D1861007175&p2p0059
> > > > >

> > > >
> > > >
> > > > ---
> > > > Visual C# - A Guide for VB6 Developers
> > > > This book will make it easy to transfer your skills
> > > > from Visual Basic 6 to C#, the language of choice
> > > > of the .NET Framework.
> > > > http://www.wrox.com/ACON11.asp?ISBN=3D1861007175&p2p0059
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > > ---
> > > Visual C# - A Guide for VB6 Developers>
> > > This book will make it easy to transfer your skills
> > > from Visual Basic 6 to C#, the language of choice
> > > of the .NET Framework.
> > > http://www.wrox.com/ACON11.asp?ISBN=3D1861007175&p2p0059
> > >
> >
> >
> > ---
> > Visual C# - A Guide for VB6 Developers
> > This book will make it easy to transfer your skills
> > from Visual Basic 6 to C#, the language of choice
> > of the .NET Framework.
> > http://www.wrox.com/ACON11.asp?ISBN=3D1861007175&p2p0059
> >
> >
>
>
>
>
>
> ---
> Visual C# - A Guide for VB6 Developers
> This book will make it easy to transfer your skills
> from Visual Basic 6 to C#, the language of choice
> of the .NET Framework.
> http://www.wrox.com/ACON11.asp?ISBN=3D1861007175&p2p0059
>