Vista and XP Users - single Front End

[Rose B]

I have an application. split FE and BE, that has been working perfectly on a
network with multiple users. One of the users has just been upgraded to Vista
and now cannot access the FE if an XP user is already on, or the XP users
cannot access if the Vista user is on. As a workaround I have created 2
copies of the FE - one for XP users and one for the Vista user, both
accessing the same BE and this SEEMS to be working OK.

Is there some kind of setting that I need to be aware of or another solution
is this a common problem?

 

[Klatuu]

It sounds like you have one copy of the FE that all are sharing on the
network. That is not good. It can cause corruption and other problems, as
you are experiencing.
Put a copy of the FE on each user's computer, not on a network drive.

 

[Rose B]

OK - thanks, that would be one solution, but the problem with that is that
when the FE is upgraded it means getting a revised copy on every user's
desktop. I realise that there are risks - but it worked fine when all were XP
users!

 

[Douglas J. Steele]

You were lucky. Sharing a front-end has never been a good idea in any
version of Access running under any operating system.

To ensure that each user has the current front-end, see the free Auto FE
Updater Tony Toews has at http://www.granite.ab.ca/access/autofe.htm

 

[Rose B]

Thanks - I will take a look at this and see if I can get it working at the
location.

 

[Paul Shapiro]

I find it simpler to have users run the application by executing a batch
file which always copies the current FE from the server to the local
workstation, and then starts the local copy. Each time they run the app they
get the current FE. Any corruption or bloating is gone the next time they
run. And it's very simple.

 

[Klatuu]

We do that here in some cases. The only issue is if there is any user
specific data in the front end. For example, we have one app that keeps
track of where the user was when the last closed the app. That is kept in
local tables; therefore, a simple copy with a .bat file would loose those
data. For this app, I use a modified version of the fe updater that updates
the local tables in the new version.

There is also the issue of possible BE schema changes that has to be delt
with.

 

[Tony Toews [MVP]]

We do that here in some cases. The only issue is if there is any user
specific data in the front end. For example, we have one app that keeps
track of where the user was when the last closed the app. That is kept in
local tables; therefore, a simple copy with a .bat file would loose those
data. For this app, I use a modified version of the fe updater that updates
the local tables in the new version.

Whereas I would always keep those kinds of changes either in a
separate MDB in the FE folder or inside the BE. Most likely in the
BE.

There is also the issue of possible BE schema changes that has to be delt
with.

How so?

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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Klatuu]

Whereas I would always keep those kinds of changes either in a
separate MDB in the FE folder or inside the BE. Most likely in the
BE.

That is a reasonable approach.

How so?

If you deploy a new FE that uses any modifications made to the BE, the BE
first hast to be updated with the schema changes.

One way, of course, is to do it manually during non working hours.
There are also many BE updater utilities available and some are written to
be launched when the FE opens.

Regardless, I am only saying when you develop your deployment method, it has
to be considered.

 

[Paul Shapiro]

I put user and workstation-specific settings in the registry. That only
works if the users stay on the same computer, but when that's the case it
keeps settings out of the FE. Putting the settings in the BE is another good
idea.

For BE schema changes, I include code that checks the BE version and knows
how to perform updates. It warns the user that this has to be run with all
other users out of the application. If the schema updates complete
successfully, the FE updates the version property in the BE. Schema updates
are cumulative, so if a location skips a few FE versions, all the updates
are still in the code and are performed in proper sequence.

 

[Klatuu]

Sounds like you are on top of it.

I put user and workstation-specific settings in the registry. That only
works if the users stay on the same computer, but when that's the case it
keeps settings out of the FE. Putting the settings in the BE is another
good idea.

For BE schema changes, I include code that checks the BE version and knows
how to perform updates. It warns the user that this has to be run with all
other users out of the application. If the schema updates complete
successfully, the FE updates the version property in the BE. Schema
updates are cumulative, so if a location skips a few FE versions, all the
updates are still in the code and are performed in proper sequence.

 

[Tony Toews [MVP]]

If you deploy a new FE that uses any modifications made to the BE, the BE
first hast to be updated with the schema changes.

One way, of course, is to do it manually during non working hours.
There are also many BE updater utilities available and some are written to
be launched when the FE opens.

Regardless, I am only saying when you develop your deployment method, it has
to be considered.

Gotcha. Yes, I have been using Compare'Em
http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEM.htm. Decent
utility although it has it's quirks. It compares your current and
your development BE MDB and comes up with the VBA code to add new
tables, fields, indexes and relationships.

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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/