Individual copies of mde front ends for each instance on users PC

[Stephen J. Levine MD]

This question is a corollary to my earlier Risks of using
centralized MDE thread:

Many users, including myself, often must have multiple
instances of an application open on their desktop at any
one time. An example of this would be comparing
information pertaining to multiple visits of a patient,
or, lets say, details of multiple lab tests.

I have come to the understanding from both the earlier
centralized mde thread, other sources, and my own
experience using microsoft access 2002, that Access often
uses properties of its component objects to store
information it needs to perform certain tasks. An
example of this would be the use of the filter property
of a child form to search for records related to a record
in the parent form (I have noticed that, when I enter a
form in Design View, often I will see the parameters of a
previous search in the filter property).

Microsoft Access applications would not be alone in the
necessity for individual copies for each instance. I
have seen this done in other applications. One method I
have seen used is to places front ends, libraries, etc.
in folders identified in part by the process id of that
instance.

I would like to ask the experts here what their thoughts
are on the question I have raised here. I personally
would like to see MS Access enhanced so that all
information specific to a session be stored in a manner
where it is unaccessable to other sessions and erased at
the end of the session. It would make application
management a lot simpler.

sjl

 

[Stephen J.. Levine MD]

"A properly designed application should not need multiple
instances of an application open at the same time. It
should be possible to handle it all in one properly
designed application." Joseph E. Meehan

An easily stated platitude, Joseph, but one that I will
challenge. I have never seen such an application.

Now, true, in the days before Windows, one had to look
things up one application at a time, and then depend on
notes and screen prints. However, nowadays, one
hopefully does not have to do this.

Given the challenge, my original question stands.

sjl

 

[John Vinson]

An example of this would be comparing
information pertaining to multiple visits of a patient,
or, lets say, details of multiple lab tests.

Well, Access *does* give you the option of displaying multiple forms,
or continuous forms displaying "multiple visits" or "multiple lab
tests". I'm not sure I understand what benefit would accrue to having
multiple instances of Access open. What specifically do you want to be
able to do that cannot be achieved with a single instance?

 

[Adam O'Neil]

I would like to ask the experts here what their thoughts
are on the question I have raised here. I personally
would like to see MS Access enhanced so that all
information specific to a session be stored in a manner
where it is unaccessable to other sessions and erased at
the end of the session. It would make application
management a lot simpler.<<

This strikes me as a weird thing to want. I've been intimate with Access
since version 1.0, and at no time have I wished for better support for
*multiple concurrent instances* of the executable. Access does let you
create multiple form and report instances at run time, but the feature is
half-baked (--because you don't get multiple instances of the queries
supporting those forms and reports--) and impractical. It was one of the
selling points of Access 95, but I don't think anyone ever made much use of
it.

Yes, there are some apps that make sense to have multiple copies running at
once. Word and Excel, for example, sort of embrace the idea--although they
only give the appearance of running multiple copies at once. What you have
now is one copy running, but its MDI windows behave like application
windows. To my knowledge there's still only 1 copy of the app running.

But Access just isn't like Word or Excel--if that's what you're comparing it
to when you say you Access acted more like these other apps. I don't
understand what that would do for you. When you say that "application
management" would be "a lot simpler," I don't know what that means. I'd have
to echo the other comment that a well-designed app doesn't *rely* on having
multiple instances running at once.

adam

 

[Stephen J. Levine MD]

John W. Vinson[MVP] write:

Well, Access *does* give you the option of displaying multiple forms,
or continuous forms displaying "multiple visits" or "multiple lab
tests". I'm not sure I understand what benefit would accrue to having
multiple instances of Access open. What specifically do you want to be
able to do that cannot be achieved with a single

instance?

John, the answer to your question is that there are a lot
of reasons why a single instance will not suffice for
displaying the information I wish to see.

1) The form I am displaying has subforms, so that, as
you are aware, it cannot be displayed as a continuous
form. The application I am writing involves
tracking "events". The master form has the event
information, including a tracking number, and then has
subforms displaying information pertaining to the event,
including related events, personnel involved,
investigators involved, reporting categorizations,
procedures involved, etc. (I am sorry that I am not more
specific but I do not want to reveal publically what the
nature of the application is). The records in each of
these subforms relates many to one to the record in the
master form.

2) It is possible, considering that multiple departments
are involved, that an event could be inadvertently
entered multiple times by mistake, each of these times
having a different tracking number. In such cases, an
investigator would need to compare the information on
each of these events before deciding that they represent
one and the same event.

3) Multiple events could turn out to be part of a larger
event or have the same root cause. Again, an
investigator suspecting this would have to examine the
records from each of the candidate events to determine
the likelihood that they are of the same root cause.

4) While it would be nice and probably ultimately
advantageous for an investigator to run a report to look
at the data to determine relationships, nevertheless the
investigator has to be able to enumerate the criteria for
the report and oftentimes, this cannot be done without
inspection of each event. Furthermore, the investigator
may not be able to write a report or have one written in
a timely manner (I know that, in my own extensive
troubleshooting experience, both informatical and non-
informatical, I heavily rely on both data inspection and
ad hoc reporting to analyze and solve a problem).

5) For efficiency of maintenance and future enhancement,
the same forms are used to enter new events, edit
information on existing events and display events.
Because the forms are used for adding new records and
editing existing ones, using them to view multiple
records at the same time could result in data being
incorrectly retained. For this reason, I have spent a
tremendous amount of effort to ensure that all forms
displayed represent the master record and/or its related
records and to prevent change of, in a parent form,
information on which a displaying child form is
dependent. I have examined the implications of allowing
this to happen on data integrity and it is more of a
nightmare than just displaying different master events in
separate instances.

6) There is nothing stopping a user from executing
multiple instances of the application on the same
computer, so that users will, out of necessity do so. I
cannot restrict the back end database to exclusive access
because that would severely interfere with the usefulness
of the system to my institution.

7) I just did a little experiment where I opened one
event record in the application and then started a second
instance. I opened the form in the second instance in
design view and found that the filter property reflected
the search criteria for the first form. I then closed
the form and looked up another event in the second
instance. I then went into design view in the form in
each of the instances and found the filters were correct
for each instance. So I don't understand how access
handles form filters, nor if the same front end could run
two instances without their interfering with each other.
This right now is a critical question for us.

Unfortunately, for confidentiality reasons, I am not
allowed on a public board to be more specific about the
nature of the application or its records. If I
substituted the correct names for the events, etc, the
application and its users' needs would be a lot clearer.
I would be willing to discuss these details offline.

I hope this answers your question as to why we need to
run multiple instances not infrequently.

sjl

 

[Stephen J. Levine MD]

-----Original Message----- thoughts
are on the question I have raised here. I personally
would like to see MS Access enhanced so that all
information specific to a session be stored in a manner
where it is unaccessable to other sessions and erased at
the end of the session. It would make application
management a lot simpler.<<

"This strikes me as a weird thing to want."

Perhaps because you have not had the experience that I
and people using my application have. Suffice it to say,
that while I have been programming since 1970 and for a
living since 1983, the initials after my name should tell
you that my primary occupation is other than
programming. Basically I limit my programming to the
medical field.

I can assure you that me and my colleagues in the
medical/pharmaceutical/laboratory medicine field do not
feel that wanting to be able to run multiple instances of
an access application is weird. Please watch the use of
that word as it is arrogant and derogatory and I do not
believe your experience entitles you to that judgement.

"Yes, there are some apps that make sense to have
multiple copies running at once. Word and Excel, for
example, sort of embrace the idea--although they only
give the appearance of running multiple copies at once"

My colleagues and I do not care whether the running of
multiple instances is real or not. What we care about is
that we can have multiple documents and workbooks open on
our desktop at once.

"But Access just isn't like Word or Excel--if that's what
you're comparing it to when you say you Access acted more
like these other apps. I don't understand what that would
do for you."

Adam, we need Access to be like Word and Excel in that we
need the information our access applications handle and
display to be handled like the information in our
documents and spreadsheets. You cannot have forms with
subforms displaying many to one information in Excel and
it is not immediately updatable in Word. Access is the
best place to keep and display this information but we
need to, like we need to display multiple documents and
spreadsheets on desktop, display multiple forms on our
desktop as well. I cannot see what is so difficult about
understanding that concept.

"When you say that "application management" would be "a
lot simpler," I don't know what that means."

Adam, I simply mean that version control would be a lot
easier. Adam, in my business, which is
medical/pharmaceutical/laboratory medicine, process
control is a requirement and if you do not have control
of your software which means that every person is on the
same version, you do not have control of your processes.

"I'd have to echo the other comment that a well-designed
app doesn't *rely* on having multiple instances running
at once."

It may be that you have never had a user who needed to do
something as complex or of the nature we are doing.
Again I stand by my belief that the statement "a well-
designed app doesn't *rely* on having multiple instances
running at once." does not hold water. Adam, one thing I
was taught in Medical School was that Always and Never
were two things a Physician should Always remember Never
to say. Trust me, I have more than enough software
experience to know that software engineers would do well
to follow this dictum.

Now let us get past arguing why I need multiple instances
and instead discuss how Access can support them, whether
they need one copy of the FE for each instance (which I
am not convinced has been adequately supported or
refuted) or whether one copy per PC will suffice (or even
why one copy per server is not considered good
practice). We in Medicine are required to support what
we call best clinical practices. The same should be true
in software.

sjl

 

[Larry Linson]

I would like to ask the experts here
what their thoughts are on the question
I have raised here. I personally would
like to see MS Access enhanced so that
all information specific to a session be
stored in a manner where it is unaccessable
to other sessions and erased at the end of
the session. It would make application
management a lot simpler.

Microsoft provides a facility for customers to make suggestions for product
improvements, and I encourage you to enter your suggestion and the reasoning
behind it at http://register.microsoft.com/mswish/suggestion.asp. My guess
is that there would have to be a "substantial number" of similar requests
for the changes to be implemented, and even if it were to be, then
implementation might be multiple versions in the future.

I'd also point out that Microsoft and others have development tools already
that can be used to create software with the characteristics you describe.
One of those, Visual C++, was used to create the 32-bit versions of Access
itself. And, because they already have such software development tools, they
may not be interested in complicating Access, which, after all, started out
to be "just a simple little desktop database". I don't think many, if
anyone, imagined just how capable Access and the Jet database engine would
turn out to be, and how many people would make it their software development
tool of choice.

One of the reasons it is so popular is the simplicity and ease with which it
can be used to develop "normal business and personal applications", few of
which have the kind of requirements you describe. And, clearly, including
the ability to create a thread-safe, multi-threading/tasking application
would make development less simple for all.

Larry Linson
Microsoft Access MVP

 

[Stephen J. Levine MD]

Larry

I am not sure of the validity of the best practice of
individual mde fe's for each client (See my latest thread
regarding the data supporting this standard). All I have
seen so far are dogmatic statements and some derogatory
remarks about our needs for multiple instances on the
desktop. I have not seen the practice standard support
to the calibre of, lets say, a medical practice standard.

Access is very convenient for developing front ends for
databases because it comes with the Microsoft Office
Suite, so we have it.

While I do not know visual C++, I would imagine it would
be more complex to do applications of the sort I am
doing. These applications are very simple in design
(About 50% thereof is doable with form wizards) but have
heavy multi-user requirements.

I do own an unopened copy of Microsoft C++ that I
purchased several years ago. I will probably look at it.

Thanks for your kind and understanding response.

sjl

-----Original Message-----


Microsoft provides a facility for customers to make suggestions for product
improvements, and I encourage you to enter your suggestion and the reasoning
behind it at

http://register.microsoft.com/mswish/suggestion.asp. My
guess

 

[Larry Linson]

Unfortunately, for confidentiality reasons,
I am not allowed on a public board to be
more specific about the nature of the appli-
cation or its records. If I substituted the
correct names for the events, etc, the
application and its users' needs would be
a lot clearer.

I concur that it was difficult enough for me to follow the less-specific
descriptions you were able to give to understand why a more-complex
application could not be developed rather than invoking multiple instances
of a simpler one. Almost certainly, it could not be done with the forms and
approach that you are using now and I have noted that medical users tend to
be the ones who either need or prefer things done or shown differently than
most business application users might think "normal". And, of course, it is
"precise and concise" questions that are most likely to get useful answers
in newsgroups.

I would be willing to discuss these details offline.

Most of us who "do newsgroups" don't do it in order to provide free
one-on-one consulting, but so that a larger audience can learn from the
questions and answers. Discussing details offline would defeat that purpose.

I am sure that you could find someone who'd be happy to contract to consult
with you. My experience is that would best be that be a face-to-face
meeting -- that you find someone with the appropriate heavy Access and
application design experience who is in your locality or who can travel to
your location.

If you can find a way to describe in more detail without compromising the
confidentiality of your project, please post back here. It has been, and
promises to be if continued, an interesting discussion. In any case, best of
luck with your project.

Larry Linson
Microsoft Access MVP

 

[Albert D. Kallal]

This question is a corollary to my earlier Risks of using
centralized MDE thread:

Many users, including myself, often must have multiple
instances of an application open on their desktop at any
one time.

Sure, and the above is very workable in ms-access. I have NEVER heard of any
real serous problems when a user launches 1 or two copies of the same
program. (and, to be fair, if you only had 1 or two users in the front end,
then you probably COULD get away sharing that front end on the server.
However, if you are taking more then 2, or 3 users, then sharing is too much
risk). So, yes, go ahead and launch 1 or 2 copies of your application. If
that application does not use some local tables for processing routines in
the front end, then you should not have a problem. I never had a problem
running 2 copies of the same database. In fact, I encourage some of my
clients to do that! Further, if you did damage, or hurt the front end, the
rest of the users in the building would not care, or be interrupted anyway.
And, as mentioned, the ability of having front ends gives you great
flexibility in write code and using temp tables. A routine can make a temp
table and put data into that table without effecting other users (a great
feature of front ends).

Microsoft Access applications would not be alone in the
necessity for individual copies for each instance. I
have seen this done in other applications.

In fact, virtually all software you have in installed on your pc...is it
not?

You don't go and install Word on the server do you ?

You don't go and install Excel on the server do you?

In both of the above applications, they products that your company
purchased. Now, YOU ARE the developer, and are using ms-access to create a
product. Why then when virtually 100% of all other software installed is
placed on your pc, and then all of sudden you are suggesting to do otherwise
with the application you developed? Did the IT department get a huge case
of brain freeze here? Are you telling me that your IT department is
suggesting that ms-word, or Excel be removed from pc's and now installed on
a server?
Why waste all that network bandwidth to load word from a server onto your pc
each time?

Is your IT people really suggesting that software be installed on the server
all of sudden? I sure hope not! Further, why waste all that network
bandwidth to drag down word, or Excel, or your application? It don't make
sense, and I cannot believe that your IT department is suggesting that
applications now be removed from the pc's, and placed on a server. You can't
do that with word, you can't do that with Excel, and you certainly can't
with your appcltions you develop also. Why the sudden change in heart as to
how things will work? Who is making this suggesting at your company?

I not trying to be harsh here, but I do want to point out that it is
standard fair to install software on each pc, and really don't think anyone
is suggesting otherwise!

Further, as mentioned, why would someone waste all that network bandwidth to
have forms, and code sent down the wire to each pc? It does not makes sense.

Remember, there is a huge difference between sharing a word file on the
server, and sharing the word application. Word is a application, and no one
is suggesting that the word application be put on the server...are they? So,
then why should we start suggesting that applications we create with
ms-access be put on the server? Like word, we certainly will put the tables
on the server, but we sure don't put the application on the server.

Surely, the IT department does not make a intelligent decision based on the
fact that you purchased word, but developed another application in house?
Why in the world would the fact that you develop a application in house make
the IT department go complete dead in the brain department and suggest now
that applications be placed on the server? There is no other applications be
placed on the server for each pc to run, so why change this now? You mean
that the criteria here is purchased software goes on each pc, but if you
develop some software, then this rule get broken?

If your IT department is suggesting that the windows applications now be
moved from the pc to the server, I have to start to wonder where this
strange idea is coming from?

Further, I would think that word, Excel, PowerPoint etc. should be move LONG
BEFORE your little tiny project gets moved to the server. So, if in fact
your IT department does move word, Excel and all software from pc's, then
guess there is some argument for moving your applications also.

To fair here, word, and Excel are designed by the developers to be
re-entrant. This means that these products are in fact designed to be run
multiple times in memory. Even more cool is that when you launch word 5
times, only ONE copy of word is actually loaded into memory (same goes for
each IE browser window you open). You can easily have 20 copies of word, or
20 copes of the browser run on your pc. However, try running 40 different
programs! (40 programs will really hurt your pc, but 20 of word and 20 of
excel will not even be felt!. So, yes, only ONE copy of the Word code base
gets loaded EVEN WHEN you run multiple copies)). So, yes, it certainly
possible to write and build appcltions that allow multiple copes (or
multiple users!) to use the SAME code base.

However, this type of application is certainly beyond what you have with
your applications you develop with ms-access. And, as mentioned, your IT
department is not suggesting to remove any other software from the pc to the
server...so, it don't make sense to move your appcltions either...does it?

 

[Albert D. Kallal]

6) There is nothing stopping a user from executing
multiple instances of the application on the same
computer, so that users will, out of necessity do so. I
cannot restrict the back end database to exclusive access
because that would severely interfere with


Actually, you can put some code in to prevent more the one copy of
your application being run. There is a little code snip here hat will
fix this for you here:

http://www.mvps.org/access/api/api0041.htm

On the other hand, you can write your code to allow multiple instances
of the same form. So, you can have forms opened more then once if you
want! I done this many times, and each form has its own filter etc
and have never caused me a problem.

I often allow multiple instances for the same form for my reservation
software. If a user is dong some data entry, or a booking and the phone
rings, my design allows the user to minimize the current form, and launch
another copy of the SAME form. Remember, ms-access DOES allow you to have
multiple instances of the same form open.

Of course, if you are lazy, you don't have to code for multiple instances of
the same form, but simply can allow users to launch another copy of the
application! I actually allow my clients to do both of the above!

If your application is multi user, then usually allowing mutilate instances
of the same form open is not a problem. And, in fact, if your application
avoids the use of temple tables, the generally little or no problem will
occur if you allow your users to run multiple copies of the front end. Those
multiple copies are not being loaded across a network which is much less
stable then a local hard disk (corruption, and reliability is often due to
the network, and placing front ends on the pc reduces this network load, and
also means that the application is safely loaded off the hard disk, and not
some flakey network).

 

[Albert D. Kallal]

In reading some of the posts here it has become clear that:


1) You don't seem to realize that you can allow multiple copes of the front
end be run.

In fact, you can do the above, and there is little, or no problem
allowing a user to run 1 or 2 or 3 copes of the front end. This works just
fine, and there is no reason not to allow multiple copies of the front end
to be run. You CAN DO this. However, you CAN NOT allow 20 users to grab that
front end across a network. (as mentioned, this is not reliable).


2) You also can allow multiple instances of a form to be opened. You have to
remember that a form with code is a class object. You can safely have
multiple instances of that form opened, and each copy will have its own
filters, variables for code etc. There is NOT A problem when you allow
multiple copes of the same form to run in the ONE application.

So, your confusing seems to be that you can't have multiple instances of the
application running. In fact, you can allow multiple instances on each pc,
and I have never experienced a problem when doing so. What you don't want to
do is to run those front ends across a network. Remember, a network is a
very noisy and suspect to all kinds of electrical interference. I heard of
companies where they turn on the microware to warm up a coffee, and problems
occur on the network. So, the time honoured practise of moving the fronts to
each pc is simply to reduce the load and possible problems on the network.
Just like a car can have a red line of 7000 rpm, we don't run that car at
that rate all day. Same goes for the network, and the less load on it the
much better the application will work.

Further, as I previous mentioned, in the case of all other windows software,
you do install it on each pc anyway, so why would you with all your
experience want to change this time honoured practice?

 

[Stephen J. Levine MD]

Albert

Thanks for this post. Yours is the most comforting I have
had on this issue. Particularly because it provides the
sort of experience I am looking for.

My experience is that a single user, including myself, is
not going to have more than two or three sessions of this
application open at one time.

I am in the IT department incidentally and I was the one
wanting to keep the application central because it was
simpler and I favor simplicity tremendously. But our IT
staff does have experience with scripts that can update
client copies of software. I am sure that we would need
to validate any such script and document that only
version-current copies are in use after its execution.
Probably the best approach would be to have it run with a
login, check to see if the shortcut is on the users
system and only copy the new program if the shortcut is
there. Also perhaps renaming the backend database
slightly with each version would render the older copies
useless without relinking, which would not be available
to the user.

With these measures, one can probably have reasonable
assurance that all copies of the front end that are in
use are version-current.

sjl

 

[Stephen J. Levine MD]

Larry

What you and Albert just clarified for me was that one
can safely run a few instances from the same fe, just not
a lot. Which directly answers the question posed here
about whether each instance needs its own copy of the fe.

Actually, at this point, there are only 3-4 sessions
going company-wide for this software although it will
increase. I am going to leave the fe of this version of
the application in a central place, but with the next
version, which will probably be done in a few months, I
will go to the client-based fe.

Thanks to everyone who answered me. I have learned what
I needed to know and have formulated a strategy
accordingly.

sjl

 

[Albert D. Kallal]

Albert

With these measures, one can probably have reasonable
assurance that all copies of the front end that are in
use are version-current.

No, I said you can safely allow users to run multiple copies of the front
end. I did not say that you can safely allow multiple users to share the
same copy on a server. There is a huge difference here!

Running and sharing the same front end on a network is a recipe for
problems. However, you most certainly can allow a user to run THEIR OWN copy
of the end multiple times and this usually causes no problems at all.

 

[Stephen J. Levine MD]

Albert Kallal wrote:
"No, I said you can safely allow users to run multiple
copies of the front end. I did not say that you can safely
allow multiple users to share the same copy on a server."

I don't think I implied that my solution would be to run
the front end on the server, but to copy the front end
from the server to each user PC. This is, I believe th
solution you are advocating and for which you have a
written a tool.

What I did say is that we need to have reasonable
assurance that all copies of the front end that are in use
are version-current, no matter where they are.

This means that if the application is used in a
pharmaceutical setting -- which is to what our business is
related -- one would have to validate that any tool or
mechanism used to manage the software, whether it is
deployed on each PC or centrally, would guarantee only
current versions could be used.

Sorry if I created any confusion.

sjl

 

[Albert D. Kallal]

Ah, very good!

I did some what miss read this on my part. (sorry about that!).

I would suggest that you consider adding a version number to the front end,
and a version number to the back end (I just use a table in the front end).
After all, usually my front end has a few tables (things like defaults for
city, area codes etc. I don't hard code this stuff, so I can move/change the
application with ease) (or re-sell it for that matter).

In addition to those standard fields in a table (with just ONE record), I
usually add a version number field.

Then, during start-up, I check a table (in the back end) that has a version
number. If they don't match, then I offer to upgrade the user. You don't
need the upgrade code thing,but my only point is to check the version, you
can and should do this.

If you think about this, going all the way back the old AppleII days, most
software does, and will check the version of the file vs the application. If
you open a old Word file, a old Excel file, a old dbase file etc, they all
have version information in them.

The whole industry has worked this was since I can remember.

I am sure you seen software do this...right?

So, do what every other piece of software does in our industry:

Include a version number, and check it against the version number in the
back end.

When you upgrade the users, right before deployment, you simply open the
table in the back end, and update that table with the new version number
that the front end has. You are done.

 

[Guest]

Joseph

It turns out that other programmers have seen where
multiple copies of an application have been used at one
time or another. I myself had to display two copies of an
application, both in our test environment so that I could
copy the setup of one client's profile of test results
into another profile created for that client, the only
difference between the two profiles being the format of
the electronic transfer of lab test requests and results.
Since this was a vendor application and did not provide a
utility for copying one profile to another, I had to do
this manually (I actually ultimately cheated and did a DML
to copy the records from one profile to another, but that
would not have been permissible in the production
environment, nor would it have been available to the
management users responsible for setting up such profiles
and accounts).

Turns out that Access will support multiple instances of
an fe on the same computer, provided that they are not too
many. This solves the problem for us.

Take care

sjl

 

[Larry Linson]

What I did say is that we need to have reasonable
assurance that all copies of the front end that are in use
are version-current, no matter where they are.

This means that if the application is used in a
pharmaceutical setting -- which is to what our business is
related -- one would have to validate that any tool or
mechanism used to manage the software, whether it is
deployed on each PC or centrally, would guarantee only
current versions could be used.

There is a description of a versioning technique that can be used to assure
that each user is running an up-to-date copy of the current front-end --
it's described at http://accdevel.tripod.com/versioning.htm. And, if my
memory doesn't fail me, I think Tony, or someone else, provided a link to
his "AutoFEUpdater" which serves a similar purpose.

The method I used had a "mandatory update" feature, and if the front-end
version did not match the mandatory version in the shared/server files, it
would simply inform the user and quit. In our case, the users were not
necessarily computer-knowledgeable, but all could click-and-drag a file from
the server folder to their own machine, so we did not use a batch file or
other mechanism to do the copy for them.

And, we published to all the users the location (server folder) from which
they could copy the current version of the front-end, if getting a current
copy made them more comfortable even though they were not getting a message
that a newer one was available or required when they started the
application. But, it's not necessary to copy down the front end _every_ time
the user wants to run the database.

It did not require renaming the back-end (which in a server environment
would not be nearly so simple as with a split Access-Jet multiuser
environment).

Larry Linson
Microsoft Access MVP

 

[Tony Toews]

nd, if my
memory doesn't fail me, I think Tony, or someone else, provided a link to
his "AutoFEUpdater" which serves a similar purpose.

But the AutoFeUpdater doesn't do any version checking. It simply
compares the datetime of the file at the time it was downloaded from
the server with the datetime of the file currently on the server.
If different it copies the new file down and updates the datetime
stored on the client.

It has worked flawlessly at my client for several years. Sometimes
I'd update the FE multiple times throughout the day. Each time when
they went back into the FE it would copy down the new one.

Actually there is one minor flaw.

If the MDB is on the client I should delete it first. For other
reasons, SQL Server compatibility, I don't allow my client to use the
app twice. If not allowed then this means that it is in use on the
client and the user is trying to run the app the second time. Coping
the MDE overtop the MDE while it is in use causes Access much anguish.
<smile>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm