Re: Homegrown synchronization

"rdemyan" <rdemyan@xxxxxxxxxxx> wrote in
news:1167422949.139736.175000@xxxxxxxxxxxxxxxxxxxxxxxxxxx:

David W. Fenton wrote:
"rdemyan" <rdemyan@xxxxxxxxxxx> wrote in
news:1167277576.600997.149500@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

David W. Fenton wrote:
"rdemyan" <rdemyan@xxxxxxxxxxx> wrote in
news:1167266561.984368.281860@xxxxxxxxxxxxxxxxxxxxxxxxxxx:

Here's a suggestion:

Have a separate front end with linked tables to your shared
database. Have the synch program use that back end, instead of
the real shared back end. Then, before it runs, have it check
to see who is using that front end, and if anybody else is
using it, prohibit it from running. You might also do things
like try to delete the LDB file, which would mean that it's
actually *not* in use. You can use the ADO UserRoster for
this, or the LDBUSR.DLL (look that up on Microsoft's website,
or on the Access Web, mvps.org/access).

You totally lost me on this one. By a separate front end, you
don't mean my main application, do you? Are you suggesting
that the sync program ("front end"?) I wrote should link to the
shared backend file on the server?

Know. I'm suggesting that instead of using the back end directly,
your synch program could use an intermediary MDB file with linked
tables and the only purpose of this intermediary MDB file would
be to provide you with an LDB file that would allow you to
restrict to one user (something you can't do when using the real
back end).

I'm not clear on why I wouldn't have the synch program link to the
shared backend.

Because that provides you a way to monitor and limit the number of
users running the synch program. If you link directly to the back
end, you can't distinguish your regular users from the user of the
synch app.

I currently use the Jet UserRoster in my main app. So
I could use it there. I believe I am correct in saying that a .ldb
file is not created for the backend until someone actually uses
data from the backend.

Not entirely. A back end file will not have an LDB just because
someone opens a front end with tables linked to it. But all it takes
is the initialization of a DAO database variable to create the LDB
file. Opening a form bound to a table will also create the LDB.

The point is that if you open an MDB, the LDB is created
immediately. Opening a front end creates an LDB for the front end,
but not for the back end. So, you could either use the intermediary
front end or run the synch MDB in shared mode (I'm not certain if
this would be risky or not).

So an app just sitting there linked to the backend
doesn't cause a .ldb file to be created for the backend.

We're not talking about the back end's LDB, but any LDB that could
be used to keep track of who is logged on. It could be the LDB for
your synch app or the LDB for the intermediary front end I suggested
(which is not really a front end -- it's just a shell MDB with table
links in it, used for no purpose except to track who has it open).

So if I link the synch program directly to the backend and am
careful in my code to make sure that all recordsets are closed and
set to Nothing, then why wouldn't this work. Before the code
applies any updates, it would first check to see via the Jet
UserRoster if anyone else is "logged in" to the backend. If so,
update will not be applied.
When the other user finishes, then the update is applied.

But how can you then apply synchs when the regular users are
editing? Or is that what you want to avoid? I thought we were
talking about how to prevent multiple users from running the synch
program simultaneously.

After an update is applied, a record is written to a table in the
backend with the details of that update file. When the synch
program timer fires it checks what files are in the dropbox and
which files have been imported. If already imported, the import
code is not run.

This seems like it should work.

I don't think we're any longer talking about the same thing at all.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

Relevant Pages

  • Re: Homegrown synchronization
    ... If the production backend, then the concern is that the code in the ... Synch app is on each each user's local PC? ... is a .ldb file for the backend file and/or use the Jet User Roster. ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... your synch program could use an intermediary MDB file with linked ... each "generation" and multiple remote databases would process it. ... then you could safely have the remote database ...
    (microsoft.public.access.replication)