Re: Homegrown synchronization


No, it looks like we're not talking about the same thing.

Sorry to be so dense. But I'm still not following you. Let me state a
few things first to see if we are on the same page.

1) Updates will be applied to the shared production backend directly,
or should it be a copy?
2) If the production backend, then the concern is that the code in the
synch app may be updating a record in a production backend table that a
user connected to the production backend is trying to update at the
same time.
3) Synch app is on each each user's local PC?
4) Intermediary app is where? On each user's local PC as well or in
the folder on the server where the shared production backend (or copy)
is. If we're trying to restrict the intermediary app to one user, then
wouldn't it have to be on the server. There's no way to control this
if a copy of the intermediary app exists on each user's intermediary
machine.
5) My plan was to launch the synch app when my main app launches; but
only for users who are given permission to do so (this would be set in
my main app when a user is setup to use the main app). The reason for
this is I want to restrict who can launch a synch app to only those
individuals who are connected to the LAN where the shared production
backend is. Sure I could not distribute the Synch app to the WAN
users, but my plan seems safer since users could still get a copy off
the server. This way I don't need to add additional instructions for
new users (the more instructions, the more confusion, the more
calls......).

I guess I just don't see how having the intermediary app tells me
anything about users who are logged in directly to the production
backend. I thought that the way to determine this was to see if there
is a .ldb file for the backend file and/or use the Jet User Roster.

Sorry, but I'm just not following you so I'll stop my post here rather
than ramble on with a false set of assumptions or understanding.


David W. Fenton wrote:
"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
    ... like try to delete the LDB file, ... shared backend file on the server? ... your synch program could use an intermediary MDB file with linked ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... the entire backend file with an update from the server. ... The synch app only creates the zipped file updates from the ... These zip files are of the production backend ...
    (microsoft.public.access.replication)
  • Re: Backend database locking up after synch through code
    ... I figured it out..the .ldb for the backend db is not being created ... When I open the front end database, ... right as it opens BEFORE the backend tables are linked? ...
    (microsoft.public.access.replication)
  • Re: Restrict FE application to one user at a time - "Exclusive" isnt Exclusive!
    ... In this case the Frontend would be looking for the LDB ... a connection to the Backend (like making a reference to a Database ... If as you said the test is done before any connection is made to the ...
    (comp.databases.ms-access)
  • LDB file
    ... i am using a asp application with acess as its backend. ... my problem is that a lock file (ex-: ... ldb) is being generated and ...
    (microsoft.public.access.forms)
Loading