By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,224 Members | 1,103 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,224 IT Pros & Developers. It's quick & easy.

How to replace a .mde file when many users are connected to the file

P: n/a
I have a compiled file (.mde) and need to replace the file. I use Access 97
and SQL-server. I have about 150 users. I have made a shortcut to the
startmenu for this file. Its impossible to replace the file when any of the
users have the file open. I often need to upgrade with new version of the
application. I find this problem very difficult.

Helge
Nov 12 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
> I have a compiled file (.mde) and need to replace the file. I use Access 97
and SQL-server. I have about 150 users. I have made a shortcut to the
startmenu for this file. Its impossible to replace the file when any of the
users have the file open. I often need to upgrade with new version of the
application. I find this problem very difficult.


The following page at Tony Toews' web site explains the proper way to implement
a split database (do NOT *share* the FE) and also contains a link to his Auto FE
Updater utility to assist in propagating updates to the font end:
http://www.granite.ab.ca/access/splitapp.htm.

--
Bruce M. Thompson, Microsoft Access MVP
bt******@mvps.org (See the Access FAQ at http://www.mvps.org/access)
NO Email Please. Keep all communications

within the newsgroups so that all might benefit.<<
Nov 12 '05 #2

P: n/a
Really bad idea to have 150 people running the same file. They really should
each have thier own copy that links to the same datasource.

Mike Storr
www.veraccess.com
"Danke" <da***@danke.no> wrote in message
news:tM9Yb.516$EV2.3571@amstwist00...
I have a compiled file (.mde) and need to replace the file. I use Access 97 and SQL-server. I have about 150 users. I have made a shortcut to the
startmenu for this file. Its impossible to replace the file when any of the users have the file open. I often need to upgrade with new version of the
application. I find this problem very difficult.

Helge

Nov 12 '05 #3

P: n/a
NB
Sigh ...
150 users relying on such a system.

Now after you learn how to properly deploy a multi-user app, check
this out

http://www.databasejournal.com/featu...le.php/3286111

It's a solution by Danny Lesandrini, very clean, and all Access-native
for automatic updating of users' front ends

I used to update frontends by Tony's free utility at
http://www.granite.ab.ca/access/autofe.htm

but now find Danny's approach better

To kick users out of the database for back-end maintenance, read this

http://groups.google.com.au/groups?h...et2.esinet.net
NB
Nov 12 '05 #4

P: n/a
ni******@lycos.com (NB) wrote:
http://www.databasejournal.com/featu...le.php/3286111
It's a solution by Danny Lesandrini, very clean, and all Access-native
for automatic updating of users' front ends
Nice article. Thanks. I've added a link to my Auto FE Updater.
I used to update frontends by Tony's free utility at
http://www.granite.ab.ca/access/autofe.htm
but now find Danny's approach better
Why? Because it's all built in Access? Or my utility is a bit quirky to figure out
and get running?
To kick users out of the database for back-end maintenance, read this
http://groups.google.com.au/groups?h...et2.esinet.net


Yeah, that'd work but it's rather abrupt. One thing to watch out for is that you
have to ensure the timer form is off when you're in VBA code. Otherwise the wrong
item when using Intellisense will kick in prematurely.

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
Nov 12 '05 #5

P: n/a
NB
> Why? Because it's all built in Access? Or my utility is a bit quirky to figure out
and get running?
It's not very easy to get it work at first try. But I did manage and
it worked beautifully. And you're right, I prefer Danny's as it allows
me to easily customize and add some flavours to it.

Yeah, that'd work but it's rather abrupt. One thing to watch out for is that you
have to ensure the timer form is off when you're in VBA code. Otherwise the wrong
item when using Intellisense will kick in prematurely.

Tony


I always politely pop up a count down form telling users that they are
being logged off in ... seconds (either due to inactivity or
maintenance work). When it's due to inactivity, the pop-up form give
user a chance to cancel the logoff (but not when it's for maintenance
work).

That timer form is really very annoying when you're in the VB editor.
I bypass it whenever I need to code something.

And Tony, your site is great. I've learnt so much there.

NB
Nov 12 '05 #6

P: n/a
Tony Toews <tt****@telusplanet.net> wrote in
news:5k********************************@4ax.com:
ni******@lycos.com (NB) wrote:

I used to update frontends by Tony's free utility at
http://www.granite.ab.ca/access/autofe.htm
but now find Danny's approach better


Why? Because it's all built in Access? Or my utility is a bit
quirky to figure out and get running?


Well, it solves the issue with your updater of having to store the
MSAccess path in your updater's INI file when you are using
something other than the default workgroup.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #7

P: n/a
"David W. Fenton" <dX********@bway.net.invalid> wrote:
Well, it solves the issue with your updater of having to store the
MSAccess path in your updater's INI file when you are using
something other than the default workgroup.


Ah, now that's a very good point. I've lived with some limitations for so long that
I can't see outside the box.

So a very useful addition then would be for it to do either of the following:
1) use whatever version of Access is associated with the mdb file extension
or
2) use a specific version of Access locatable by using the registry keys such as
SOFTWARE\Microsoft\Office\8.0\Access\BinDirPath
SOFTWARE\Microsoft\Access Runtime\8.0
or simlar

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
Nov 12 '05 #8

P: n/a
ni******@lycos.com (NB) wrote:
Why? Because it's all built in Access? Or my utility is a bit quirky to figure out
and get running?
It's not very easy to get it work at first try.


Agreed. I figure if I make some simple changes to the names of the lines in the INI
file it will become much easier to understand the first time. And save a lot of
frustration.

Lines such as
SourceDirectory=z:\your product\Server FE directory
TargetDirectory=c:\Workstation FE directory
StartupFile=Your FE name.mde
But I did manage and
it worked beautifully. And you're right, I prefer Danny's as it allows
me to easily customize and add some flavours to it.
Understandable.
That timer form is really very annoying when you're in the VB editor.
I bypass it whenever I need to code something.
What I do is I only ship MDEs to my users,etc. So on that hidden form with the timer
I have it check for if it's an MDE or not. If an MDE then I turn the timer on.
And Tony, your site is great. I've learnt so much there.


Thanks for the comments. Makes the effort worthwhile.

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
Nov 12 '05 #9

P: n/a
Tony Toews <tt****@telusplanet.net> wrote in
news:3m********************************@4ax.com:
"David W. Fenton" <dX********@bway.net.invalid> wrote:
Well, it solves the issue with your updater of having to store the
MSAccess path in your updater's INI file when you are using
something other than the default workgroup.


Ah, now that's a very good point. I've lived with some
limitations for so long that I can't see outside the box.

So a very useful addition then would be for it to do either of the
following: 1) use whatever version of Access is associated with
the mdb file extension
or
2) use a specific version of Access locatable by using the
registry keys such as
SOFTWARE\Microsoft\Office\8.0\Access\BinDirPath
SOFTWARE\Microsoft\Access Runtime\8.0 or simlar


Yep.

Jeremy Wallace uses a batch file with IF EXIST to test for the
existence of the default Office directory, but that doesn't work
very well.

If your updater could get something from the registry, that would be
helpful. I'd rather it not use the default or guess, but be
something where you could tell it to use A2K or A97 or whatever.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #10

P: n/a
> http://www.databasejournal.com/featu...le.php/3286111

It's a solution by Danny Lesandrini, very clean, and all Access-native
for automatic updating of users' front ends


I agree with Tony - that's a slick approach. Thanks for posting that url.

--
Bruce M. Thompson, Microsoft Access MVP
bt******@mvps.org (See the Access FAQ at http://www.mvps.org/access)
NO Email Please. Keep all communications

within the newsgroups so that all might benefit.<<
Nov 12 '05 #11

P: n/a
"David W. Fenton" <dX********@bway.net.invalid> wrote:
If your updater could get something from the registry, that would be
helpful. I'd rather it not use the default or guess, but be
something where you could tell it to use A2K or A97 or whatever.


Agreed. That the person doing the configuration should state what version of Access
to use. That said it would be nice if the utility could be configured for multiple
versions of Acces which some folks, such as my client, have installed. Then it would
copy down the appropriate file as required.

Right now they have three INI files and two FE directories. One INI file for A97.
Another INI file for A2000 installed locally. Another INI file for A2000 installed
on the Citrix server. It'd be nice to have that all in one INI file in an coherent
and logical layout. <smile>

Now what I could also do is examine the bytes at the beginning of the MDB/MDE file
and figure out what version of the MDB/MDE really is. But that kind logic is getting
pretty complicated.

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
Nov 12 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.