Set a Flag to Download Files from Application Launcher

[rdemyan via AccessMonster.com]

Okay, I hid the title a bit because I'm probably going to get some flame mail
on this.

First let me say that data is only updated in my application tables once or
twice a month. It is mostly an application about performing complex
calculations and analysis not an application where data is added/modified on
a daily basis.

The servers are excrutiatingly slow so I give my users the option of
downloading the backend file from the server to their local PCs. Then when
we add or modify data (once or twice a month) we send out an e-mail. The
next time user's login, they check a box on the launcher and when the
application opens it automatically downloads the back end file. User's are
well aware that there is always a possibility that the data may be uptodate,
but everyone downloads (it's not a requirement) because of the speed at which
data is then accessed.

To give you an idea, last week I logged on from a remote location and it took
20 minutes just to login (the front end was on the local PC at the remote
location). If the back-end files are on the same PC as the front end it takes
about 20 seconds. So I think you see why we have to do this. Admittedly
this was a worst case situation because I was well removed from the actual
geographic location.

We have not set the launcher up to download the backend files every time the
user logs in. While this would keep the data up-to-date, it typically takes
about 10 minutes to download the file. Users can download every time if they
want to, but we don't force it on them.

Here's the issue. I'd like to see if I can automate the downloading process.
This would eliminate the need for us to send an e-mail and the user wouldn't
have to remember to check a box on the launcher.

Maybe a table in the backend which contains a flag or date that we set when
we add/edit data. Then the launcher can open this table and check the value.
If the flag is set, the launcher then will pass the instruction (via Command)
to the main app to download the backend file. I can do this, but I'm unclear
on how to turn it off. That is once User A has the new backend file, what's
the best way to stop the new backend file from being downloaded the next time
User A logs in.

I guess I could have a table in the front end that writes a record indicating
that the backend file has been downloaded. Maybe both the table in the front
and backend should record the date. The date could then be compared during
launching of the app to decide if the backend file should be downloaded. If
the dates are equal, no download. If server date is > local date, then
download.

Comment, suggestions, are very welcome. Yes, I know that in principal all
users should be linked to the back-end file on the server, but in our case
we've been doing it this way for quite some time with no problems. But that
is only because we update the tables infrequently.

Thanks.

 

[Albert D. Kallal]

how about check the date of the two files, one on the local pc, and one on
the server?

Tony has a autoFE updater here:

http://www.granite.ab.ca/access/autofe.htm

Perhaps, you use the above?

On the other hand, perhaps you can move the back end to a true database
server (a free one has been included for the last 3 versions of office
(since a2000). Further, there is sql express. That makes 2 free ones from
Microsoft. (and, there is others like MySql). So, you have a good number of
free database servers available, and you could continue to use your front
ends in ms-access. That way, you would NEVER have to update users, they
would always be up to date, and further, you could actually allow users to
modify data (if needed).

Comment, suggestions, are very welcome.

I outline some solutions to working with a slow network here:

http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html

 

[rdemyan via AccessMonster.com]

Thanks for the reply Albert.

You mean check the date shown in Windows Explorer for the files? I have to
check but I guess it doesn't change just because someone is connected to the
back-end file. If this could work it has the advantage of not having to open
the backend file to check some table.

However, now that I think about it some more, I don't think it will work
because the back-end files on the server are backed up and compacted at least
once a week. Maybe we don't have to do this so frequently unless we add data.
What are your thoughts on that?

 

[Albert D. Kallal]

You mean check the date shown in Windows Explorer for the files? I have
to
check but I guess it doesn't change just because someone is connected to
the
back-end file.

Exactly my point! You *would* change the date *when* you need to force out a
update to your users.....
You would compare the date on your local, vs that of the one on the server.

I mean, really,a simple text file with a date value in it could be opened in
place of that back end mdb anyway (and, that likely would be faster!!).
After all, if I understand you correctly, no users are opening the back end
anyway.

So, don't bother with a flag, but a simple text file with a date in it could
suffice.

If this could work it has the advantage of not having to open
the backend file to check some table.

Yup...exactly my thoughts. (I like the simple text file idea even better).

However, now that I think about it some more, I don't think it will work
because the back-end files on the server are backed up and compacted at
least
once a week. Maybe we don't have to do this so frequently unless we add
data.
What are your thoughts on that?

Backup, and compiling once a week sounds good to me.....

So, if moving the data to some free database server is not possible (and you
should consider that), then perhaps the text file idea would work...

 

[rdemyan via AccessMonster.com]

Yeah, but when we backup and compact, that changes the date on the backend
file regardless of whether the data has been updated or not.

Ahh, but I see, it wouldn't change the date contained within the text file.
The text file would still have the same date in it and, of course, be
unaffected by the compact.

But, I'm not sure how I would go about creating the text file. My app is
very code intensive, so does this mean I have to have a routine that is
called in every area in the code where data is being updated. That could
easily be several hundred or more.

 

[Albert D. Kallal]

But, I'm not sure how I would go about creating the text file. My app is

very code intensive, so does this mean I have to have a routine that is
called in every area in the code where data is being updated. That could
easily be several hundred or more.

I was under the impression we are only talking about one back end mdb file
here?

You need something that tells your software when to download this "updated"
data file?

I was thinking along the lines that your start-up code would simply check
that text file date. If it is greater then the "last" update date (which
could be in a text file in the local dir, then you simply download, and then
update your *local* text file to that date. I don't know why you would check
in several 100 places? I assumed this big file download is a all, or nothing
kind of deal...not table by table. (or, if you even have more ten one
table).

 

[rdemyan via AccessMonster.com]

I can figure out how to check the text file in the startup code; not a
problem.

No, how do I CREATE the text file when a user updates something in the back-
end files (actually there are two of them). By checking a couple of
hundred I meant that I probably have at least a couple of hundred save
routines for various parts of my app. So when a user saves new data, does my
save routine (for that part of the app), call a subroutine that creates the
text file?

Yes, the download would be an all or nothing thing.

Thanks.