Geosync usage guidelines

Updated 2009-09-24 | Filed under Geosync | PDF

Move Tables or Rename Tables

Any table that you do not want replicated may be relocated to the frontend file. This of course would mean that in your multiuser locations the table is not shared. This is best reserved only for static list tables.

Another idea is to rename a table, giving it a unique table name per backend file. These tables then will not consolidate data because they have differing names. However renaming a table is an extreme solution that must not be entered into lightly as it requires all objects (queries, forms, reports, custom VBA) that are sourced on to all be modified as well.

Embedding a GeoSync trigger into an event

By default, a sync only occurs when you manually click the EQL Synchronize toolbar button. In order to ensure that regular synchronizations are occurring, you can use a VBA script or macro to sync your database with the server whenever you want. To initiate a full two-way sync, just run EqlSync(). Alternatively, you can run each half of the EqlSync operation independently.

EqlSync is equivalent to: 

EqlPush()
EqlPull()

EqlPush sends all updated data to the server, but doesn't ever change your local database. EqlPull does the opposite; it retrieves the most recent version from the server and replaces your database contents with it. It is safe to run EqlPush as many times as you want without running EqlPull; this is a good way to back up your database and have others see your database edits, even if you aren't interested in seeing other people's changes yet. You can also run EqlPull whenever you want, and you will receive all the changes other people have sent to the server. However, you will lose your own local changes unless you have first run EqlPush.

Front End design suggestions

If you rely on the manual trigger for database synchronization, you must ensure to remind users of the database to perform the sync operation in order to ensure their changes are shared in a timely fashion, and they are working with up-to-date data. You may wish to add a pop up form or some other method to remind the user. By embedding the trigger, the sync can occur at whichever event(s) you select. There are some considerations to keep in mind with this approach. For example, in a multi-user split database environment within one office space, if you embed the sync trigger in the opening form's OnLoad Event – it would sync multiple times as everyone first opens their Access application. Since everyone is sharing the same back end tables it would not be necessary to sync the data multiple times. In this case you would probably want to embed the trigger in one primary application only – not on every PC. Alternatively, you could write a more complicated VBA script containing an 'Am I First?' routine so that the first user to log on would trigger a sync.

Front End Variations

It is not uncommon that a split database have variations of the Front End file that alter/limit the feature set for differing classes of users. An FE for executive management may differ greatly than the FE used by line employees but link to the same Back End files. This will not be affected by the Geosync process.

However there is a design consideration. Those FEs that trigger the Geosync must be a descendent copy of the master database in order for the Back End files to be known as within the same user group. If an existing variant Front End (i.e. built for data entry only to be used by line employees) is not to trigger the Geosync then it would not have to be rebuilt. However if the variant FE is to trigger the Geosync then it must be rebuilt from a copy of the master database.

Related Articles

Unrelated Articles