Hi,

I'm just wondering what my options are at the moment. I'm developing a
database application that will be shared between a number of sites.
Remote Desktop Apps are my initial intention, but after reading a bit
about the PUBLISH option in EDB, I was wondering what other options may
be available to me with EDB.

The sites will not have very good speeds amongst them. Since they're out
of town the only internet connection they have is the mobile phone network.

Does EDB give the facility of caching data locally (so users can edit
data and publish periodically) and post those changes to the server when
changes are made and if so - would this be a feasible option over a
slower connection - or should I stick with my original thoughts about
using RDP?

I did something similar to this back in the late 90's with MIDAS.

Cheers

Adam.

Adam


The publishing feature is essentially database replication so what will happen if you go down that path is that every user/node will have a complete version of the data stored locally.

It will probably be a very good option for the sort of network you describe just that it will have some time lag in the data being kept up to date. That may or may not be a problem depending on the frequency of updates and just what they're doing with the data.

I don't know how good the mobile connection would be but if its dire or dead slow and if dead slow the published data volumes are large (highly relative term) then Citrix, RealThinClient or somesuch may be more suitable.

How's that for hedging my bets?

Roy Lambert [Team Elevate]

Hi Roy,

> The publishing feature is essentially database replication so what will happen if you go down that path is that every user/node will have a complete version of the data stored locally.
>
> It will probably be a very good option for the sort of network you describe just that it will have some time lag in the data being kept up to date. That may or may not be a problem depending on the frequency of updates and just what they're doing with the data.
>
> I don't know how good the mobile connection would be but if its dire or dead slow and if dead slow the published data volumes are large (highly relative term) then Citrix, RealThinClient or somesuch may be more suitable.
>
> How's that for hedging my bets?

LOL - sounds pretty good.

It's good to know that there are various options available for this.
Having a complete version of the data stored locally doesn't worry me
too much - provided that I can restrict certain features to instantly
update before and after. (ie, such as adding a new invoice, so numbers
don't conflict or go out of sequence).

This publishing feature could be quite handy.

Cheers

Adam.

Adam H.

I use EDB for the exact implementation you describe. I have farm-inspectors visiting 1,000s of farm sites with laptops, plus multiple regional offices where data is also input.

I use EDB replication exclusively. It is tricky & complicated, but pretty much magic ... the users love it & it works well. I wouldn't possibly think of replacing it with a WAN type system (or Cistrix) now I have it working.

1. All users have a local copy of the data so the app is super fast. Downside: All users have opportunity to hack the DB as it is right on their laptops ... so encryption may be vital.

2. You have to ensure that what I call the "clockwork" (all the procedures being run by EDBSRVR to sync the data) are clean & work well.

3. Changes to the DB structure become much more complicated, as you have many instances of the DB to update, and there is the potential to "leave behind" a user who is updating data with an out of date version of the system. HOWEVER: I have figured out a really neat way to deal with this problem!

4. Server set-up becomes complex as you need large numbers of STORES on the server to manage all the clockwork.

If you would like more info, do email me direct on adam[at sign here]fullwellmill.co.uk

Adam


If you do put something together I for one would love a copy.

EMail address is as here.

Roy Lambert

<If you would like more info, do email me direct on adam[at sign here]fullwellmill.co.uk>

I'd be interested too. I'll send you an email.

Barry

Hi Adam,

Thanks very much for your offer. I've sent through an email, as I too am
very interested in how you have done this.

I'm in a situation where I need to make sure that if someone inserts a
new record for some tables (lookup tables for instance), that it is done
on the main database to ensure that people don't double-up recordid's. I
assume you do this too in your application?

Cheers

Adam.

"Adam H." wrote:

Hi,

I'm just wondering what my options are at the moment. I'm developing a
database application that will be shared between a number of sites.
Remote Desktop Apps are my initial intention, but after reading a bit
about the PUBLISH option in EDB, I was wondering what other options may
be available to me with EDB.

The sites will not have very good speeds amongst them. Since they're out
of town the only internet connection they have is the mobile phone network.

Does EDB give the facility of caching data locally (so users can edit
data and publish periodically) and post those changes to the server when
changes are made and if so - would this be a feasible option over a
slower connection - or should I stick with my original thoughts about
using RDP?

I did something similar to this back in the late 90's with MIDAS.

Cheers

Adam.

Regarding the Key question, I use a different "Site ID" for each each remote DB. The Main DB is always 1.
Primary Keys for each record in a table are constructed as Site ID + next available record number. This way each DB can create it's own primary keys with no conflict between DBs. The tricky part is making sure that each DB knows it's own Site ID. I do this with a Site table.
An advantage to this approach (as opposed to using GUIDs for example) is that it is easy to determine which DB added any record.

I also keep a central table on our web site that tracks the current version for each Site(DB). The Replication App checks the DB against this table to insure that it is not trying to Synch when it is out of date. It also is used to only allow a remote Site to update if the Main Site has already updated. Jobs schedule updating for night time updates (Main Site earlier than the Remote Sites). Jobs also control the replication particularly the frequency.