Thanks for your suggestions Wes.  Your second one looks to be a real option for
my situation.
I hadn't mentioned that my app is currently designed around a Paradox database.
I'm unsure what is involved in converting it to Sybase (or any other database
for that matter).
Are you able to comment?
What other databases are there out there that support replication?
How does the replication software arbitrate about where corrections can be
made?  ie if a correction is made at HO does the system know that is the correct
data and not merely overwrite it with the remote data again?
Mark

Wes Edwards wrote:

> Two types of solution, depending on your requirements for how up to date the
> data should be:
>
> - if you always need to have access to up-to-the-second data then some sort
> of live on-demand connection to a central database at HO looks like the
> solution.  This could use a dial-up LAN connection or Winframe etc.
>
> - if you can afford for your data to be a little old you can use database
> replication and gain significant speed advantages.  This is a good solution
> if each office's records are fairly self-contained and the HO only needs to
> report on the consolidated data periodically (say daily or monthly etc), and
> the remote offices also want reports/ queries.
>
> Using database replication you have a separate database (same structure) at
> each site.  The Master database then looks after keeping itself and the
> Slave databases up to date.  For example we use Sybase SQL Anywhere for our
> operations.  HO in Auckland, Offices in Melbourne, Sydney, London etc.
> Sybase's database replication makes sure that records entered in any of the
> offices can be seen in the other offices, but there is a time-lag.  This
> doesn't matter for us because we run reports weekly, or if we run reports at
> other times we understand that it only includes data since the latest
> update.
>
> As Sybase's replication mechanism has various modes of updating (including
> email, FTP etc) it is very flexible.  Also, because this is a function of
> the database server we don't have to worry about coding any of this
> ourselves, we just connect to the local database where we are.  This gives
> very fast performance.  If you want to run a query on all the data from a
> remote office you have all the data locally.  No waiting for the data to
> travel over a slow pipe from HO.
>
> For more info check out sybase, including
> http://www.sybase.com/products/anywhere/remote2.html
>
> Wes Edwards
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > Behalf Of Mark Howard
> > Sent: Tuesday, 8 February 2000 14:28
> > To: Multiple recipients of list delphi
> > Subject: [DUG]: Application Structure
> >
> >
> > Hi  (not sure if this should be Off Topic)
> > Some advice please.  I want to understand:
> > FIRST what is the simplest, least expensive solution that is
> > *possible*
> > SECONDLY what are the practical downsides of taking this simple
> > option compared to the "Ideal"
> >
> > Situation
> >
> > Client has 3 sites around NZ - both islands - one site doubles as
> > Head Office.
> > Want each site to be able to enter data and generate reports from
> > a database (same structure at each site).
> > Head Office needs to be able to generate site reports and
> > consolidated reports.
> > NOTE: We are talking a MAXIMUM of only 60 transactions per day
> > from each site.
> >
> > If my application is currently running with up to 5 users on a
> > LAN does it follow that it should also run OK on a WAN with dial
> > up lines?  If not, what are the problems?
> > What sort of communications setup does the client need to
> > organise?
> > What changes do I need to make provision for in my application eg
> > do I need to upgrade to C/S?
> > Is it an option have separate databases and to arrange some sort
> > of consolidation each day? Prefer not to have to go this way.
> >
> > I've had no experience with this sort of communications at all so
> > words of one syllable again please.
> > Again, I Stress,  I'm not after a "corporate" solution - just a
> > low cost practical one.  (No offence to those with "Corporate"
> > names!)
> >
> > TIA
> >
> > Mark
> >
> >
>
> ---------------------------------------------------------------------------
>     New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
>                   Website: http://www.delphi.org.nz
begin:vcard 
n:Howard;Mark
tel;cell:(021) 477 564
tel;fax:(07) 348 8178
tel;work:(07) 348 8177
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
fn:Forest Production Systems Ltd
end:vcard

Reply via email to