Synchronization Module

[Lisa]

I wanted to set up a task that would run night to open my database and having
a module that runs on open that would synchronize to all the databases. Is
there code to do a synchronization?

Thanks.

 

[David W. Fenton]

I wanted to set up a task that would run night to open my database
and having a module that runs on open that would synchronize to
all the databases. Is there code to do a synchronization?

Do you mean that you're using Jet replication? Why do you have
multiple replicas on the same network? If all users can access the
network, then why not have a single back end?

The proper way to do this is to schedule it using the built-in
replication schedule. Replication Manager provides the best UI for
that (though it's not a great UI), but ReplMan is not very available
these days. The TSI Synchronizer (see http://trigeminal.com)
provides a programmatic interface to it, but it's kind of confusing
(as it's a very weird type of structure and not at all intuitive).

I suspect that you're doing something wrong, such as synchronizing
front ends, and that's why I'm asking questions instead of answering
yours.

 

[Ron2006]

The real question that Dave is asking is:

What do you mean by "synchronization"?


More detail would be helpful, otherwise we are just assuming we know
what you mean.

Ron

 

[Lisa]

I have a database that I sync to 8 different server locations throughout the
country. The master copy is on my local server. So there is no backend at
this point because I haven't been able to figure out how to properly split
the database and be able to link the front and backends on each server. So I
guess the answer to your question is that it is a database that has the data
tables and the forms all in one database.

So when I make updates in the master (to forms, reports, etc) I can't sync
unless everyone is out of the database and because of time differences that
is very difficult. So the answer for me was to run the synchronization in a
job that would run at the West Coast has gone home.

I hope that this information makes sense. If not I can clarify further.

Thanks.

Lisa

 

[David W. Fenton]

I have a database that I sync to 8 different server locations
throughout the country. The master copy is on my local server.
So there is no backend at this point because I haven't been able
to figure out how to properly split the database and be able to
link the front and backends on each server. So I guess the answer
to your question is that it is a database that has the data tables
and the forms all in one database.

So when I make updates in the master (to forms, reports, etc) I
can't sync unless everyone is out of the database and because of
time differences that is very difficult. So the answer for me was
to run the synchronization in a job that would run at the West
Coast has gone home.

Basically, everything about your setup is, unfortunately, WRONG.

The solution to your problem is to host the app on a single Windows
Terminal Server and have the remote users run the app there.

The reasons you are in the wrong:

1. Jet replication doesn't work reliably for front end objects
(forms/reports/etc.). If you continue to synch your unsplit
database, you're likely to end up with a completely corrupted Access
project that will be completely unrecoverable.

2. direct synchs across anything other than a WAN are EXTREMELY
DANGEROUS, because it opens the remote database across the wire. Any
dropped connection during a synch will corrupt the remote MDB and
likely render it unreplicable.

You can easily split the app and provide the users a UI to reconnect
to their local back end. One solution is to place the local back end
in the same folder as the front end. Code for both of these has been
posted in these Access newsgroups literally thousands of times.
Search Google Groups for "relink".

Once you've done that, you'd still need to synch the back end data,
and the only safe way to do that is to implement indrect or Internet
replication, which requires outside components and significant
coding expertise.

This is why I recommend the Terminal Server solution. It puts all of
your administration in one place and eliminates any need for Jet
replication at all.