Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 8 of 8 total |
Multi Site Application with Cached Data |
Tue, Feb 5 2013 12:48 AM | Permanent Link |
Adam H. | 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. |
Tue, Feb 5 2013 4:24 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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] |
Tue, Feb 5 2013 5:13 PM | Permanent Link |
Adam H. | 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. |
Wed, Feb 6 2013 6:33 AM | Permanent Link |
Adam Brett Orixa Systems | 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 |
Wed, Feb 6 2013 7:50 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
If you do put something together I for one would love a copy. EMail address is as here. Roy Lambert |
Wed, Feb 6 2013 1:12 PM | Permanent Link |
Barry | <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 |
Wed, Feb 6 2013 7:30 PM | Permanent Link |
Adam H. | 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. |
Mon, Apr 15 2013 10:32 AM | Permanent Link |
Jim Garrity SDS | "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. |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |