-----Original Message-----
From: Nic Wise <[EMAIL PROTECTED]>
To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
Date: Saturday, 29 January 2000 00:28
Subject: Re:[DUG]: MIDAS - Here we go again....
>* 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??
Yep, and just write em out as XML for safe storage, and just declare what
ever indexes you want on them. Only constraint might be if you poke so much
stuff at the CDS that you run out of RAM on the client machines, still you
can surely invent a just in timne caching scheme?
>* 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.
I think you can just cache all the latest stuff at the App server, and force
a refresh from the server to the clients. At the moment AutoRefresh at the
Provider is not implemented, so you will have to do this yourself. In
effect, Midas actually does what you want without having to actually do
anything special. ie If you force your client CDS's to Autorefresh, and
CDS.SaveToFile at your client, then I suspect you have exactly what you
want. The fact that CDS can save as an XML may also have some hidden
advantage for you?
> 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....?
Or force it to happen from the Appserver
> 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.
CDS is blindingly fast. Use it. The only trap to watch for with CDS is if
you get to much data. I ran into a problem this way when caching abut 800Mb
in a CDS, because it simply went over the top of all available memory. CDDS
does not automatically write to a file like Cached Updates do, so you may
have to do something yourself about flushing it.
>This is obviously done using local BDE.
Not always - see above.
BDE is dead. For new apps you should really look at other texhniques (ADO,
IBX, Oracle Direct Access etc...)
>>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
Mid What? Use Midas. Its cheap. If its to expensive for you, then I sugest
you n tier is the wrong techniques for you. The cost of Midas is small
compared to the copst of buildinbg any n tiered App. Midas is going places.
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)
What you do here is add an extra column type Integer, get a trigger to inc
this column whenever any change occurs to the table, then just in time
before selecting anythng from you CDS, you do a Select Max(CheckColumn) from
T and compare it to your local check sum held at the server for that T and
if changed, then you need to refresh your local cache.
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.... :)
Dont think you need to bother with any of this... Just force an Autorefresh
out to all your Midas Clients.
Good Luck...
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
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
