>* Using MIDAS
>* 3 Tier Model (Presentation, Application, Back End)
>* One "Master" Database on Back End Tier
>* Bunch of local database copies (One copy per client)
I'm not 100% sure, but couldn't you use client data sets for this??
>* Clients on presentation layer can either be updaters (can update the
>"Master") or subscribers (They want their local copy of the data updated
>when there is a change to the "Master") (Potentially Updates could also be
>subscribers)
>
>I know we have gone over this, but I still have some questions:
>2. Have any changes made to the "Master" database via the application server
>come back to all the clients in some form so that their local databases can
>be updated
Are they all, always, on the same subnet? Getting a push trigger is not easy (lots
of registration) and using pull is time consuming and wastefull - how about using
UDP broadcast - you have a thread or similar running in the background on a
subscriber, nd it just polls the DB when told to - the updater fires a message
around saying "new stuff" when its in there. Not very difficult. I did a similar
system to this for a uni project - had an SGI doing the processing (image analysis),
which would then fire out the processed data (X,Y co-ords) via UDP - and X clients
would then pick it up and display it. Worked very well.
>Could this be done in some way with MIDAS?? Perhaps have application servers
>on the clients that were called from the "Master" application server to
>apply updates to the local database copies.
Could work, but it would be MESSY.
> The other option would be to do
>this with some connection protocol that passes the relevant SQL statements
>as strings from the Application Layer to the Clients. This would be easy to
>achieve with MidWare
As I said above, why not just have the clients listening for a 'go get it now'
message, maybe with a minimum PK id, and have it poll the DB for it....?
> 3. Have all subscribers (read only) use their LOCAL data for queries
Look into using Client Data Sets for this - could be more efficient and automatic
than using the BDE/paradox/whatever.
>This is obviously done using local BDE.
Not always - see above.
>>From the 3 issues above I see that:
>
>1. Is made easy and robust with MIDAS OR Tricker & possibly less robust with
>MidWare.
>2. Is still tricky. Would have to be done without MIDAS.
>3. Is simple BDE
This would be my take:
1) SQL RDBMS backend - one of them only. Interbase/MSSQL/whatever.
2) updaters update it via a MIDAS server. No brainer.
3) subscribers resynch when told to. (ie, select * from table where auto-inc-key >
:the-biggest-one-I-got-last-time)
4a) the updater has a UDP socket that fires out a message to either a central
machine, or broadcasts it to the network (not much traffic, really) - which works
well if they are all on the same logical segment (10.x.x.x or 192.168.1.x). The
subscriber has a listening UDP socket (same port) that flags something to say
"refresh the table now"
OR
4b)the updater calls a routine on the application server, which signals a singleton
object somewhere in the app server that has a get-stuff/dont-get-stuff flag - and
that either (somehow :) ) notifies the clients, or the clients simply poll this value,
rather than polling the DB every time.
I still think I'd go for a UDP-based trigger - then, if you miss it, the sender
doesn't
break (unlike TCP)....?, tho the other one would work.... :)
Nic
--
Nic Wise - Human (just)
ph: 09.277.5309 / cell: 021.676.418 / em: [EMAIL PROTECTED]
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
