On Sun, Dec 4, 2016 at 12:36 AM, Kirk Brooks <[email protected]> wrote: > > > Does anyone have experience using a scheme like this? The situation is one > database that is mainly concerned with creating and actually working with > the data. Then there are these ' > > satellite' locations that run a different > database that is based on the same structure and data but has different > forms and methods. So the "main" (we'll call it) datafile is periodically > sent to these other locations to be installed. Occasionally the satellite > locations will move a datafile back to the "main". >
Kirk, perhaps can you accomplish this just a little differently, yet still achieve the same goal in the end. We do something similar with satellite sites that all consume their data from one "master" 4DServer "data center". Some of the remote sites have unique specialty field/table combos of their own, but all of them get their core data from the central source with field/table combos that 100% mirror the master database. We "sync" these remote field sites on some sort of schedule anywhere from 5 min to 24 hours normally, by waking up an export routine that finds all the new/modified records since the last export and exports all new/modified data to that site. One export schedule for each remote involved. The remote site wakes up on a matching schedule and imports that data. This way we have some sites that are 100% "up-to-date" every 5 mins. Others are up to date daily, weekly, etc. We have some projects that require the central master data to retain some data that is created only on the satellite site, so the same applies in reverse: the remote site exports and the central master imports when each awakens. We've worked out a scheme over the years to facilitate this 2 way traffic logic that works perfectly. The difficult part is having a "common dump folder" accessible to both master and satellite to deposit and consume these modified record exports/imports. Back in the v1.x - v3.x days before the web or built in 4DSync or SOAP solutions, we kept world wide data centers in sync this way using Compuserve, and later other more robust "email" providers. We've boiled it down these days to two: SOAP for small exchanges that require real time exchange -- and an AWS S3 bucket "dump folder" accessible to each 4D installation for those much larger exchanges that can be thousands and thousands of records at times. We've found over the years that "real time" exchange is troublesome when you have large exchanges. These two master/slave sites are often in very distant locals and time zones and we've come to appreciate the elasticity of this method of exchange that doesn't rely on real time connection and response from both at the same time. If something happens at one end of the other, no problem. Either roll back the "last updated" timestamp (a simple site specific record field) and trigger the export/import again - on either or both sides. Or just let it hit the next sync normally once whatever kink is worked out that made the last sync fail -- power went off somewhere, lines were cut somewhere, somebody in xyz location was working on hardware at 4am their time and had the computer down during that sync time. etc etc etc. This has been working world wide for us since 1988 with literally tens of thousands of database installations over that time. It is low tech, human eyeball understandable, and reliable. And it is easy to debug if one archives each exchange instead of deleting the export file once consumed. AND it allows one to totally build a new site or replace an old site by simply setting the "last updated" timestamp so that the entire database is exported at once. There are obviously pitfalls depending on the rules you embed or the needs you actually have. But it is worth thinking about for what you have described. ---------------------------- Steve Simpson Cimarron Software ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
